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PREFACE 


The original intent of this study was to provide a worltahle design, and corresponding cost 
estimate for an OCC that would meet the requirements of the Landsat-D system. This design, 
as an initial premise, was to make maximum utilization of the existing Landsat 1 and 2 OCC 
design concepts. 

After the study was underway, a contract modification was made to include the investigation of 
the compatibility of the Landsat-D OCC with the Payload Operations Control Center Network 
(POCCNET) concept. This study does not address the detailed design of a POCCNET based 
OCC for Landsat D, nor does itinclude cost estimates for such a design. Further, several 
aspects of the MMS based Landsat D were not included due to study scope limitations. 

Although these omissions are important for completeness, their impact on the basic study 
conclusions is felt to be negligible. 

In the interests of continuity to the reader these efforts are presented as two relatively com- 
plete reports. The initial study objectives (without consideration of POCCNET) are reported 
in Section 2 and the revised objectives ( with consideration of POCCNET) are reported in 
Section 3. Each section (Section 2 or 3) has been developed as a complete stand-alone section 
without extensive cross referencing in order to provide the reader with start-to-finish continuity 
within a section. However, tills does imply that some material in Section 3 lias been replicated 
from Section 2; the replicated material is identified for the reader who reads the whole report 
by an asterisk following the section title. 
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SECTION 1 


INTRODUCTION AND SUMMARY 


l.l BACKGROUND 

The pressing need to better survey and manage the earth's resources and environment lias 
prompted man to explore the possibilities of remote sensing from space. Earlj' elTurls 
began with space photographs from the Gemini and Apollo programs and continued with multi 
spectral data from Landsat I and 2 spacecraft. Landsat D is currcntlv planned as tin- m .,t 
major step for the Earth Resources Program. 

l.andsat 1, launchecl in 1972, marked the start of NASA's Earth Rtiscuirces satellite progr.iju. 

This successful spacecraft was followed two and a half years later with Landsat 2, an iden- 
tical spacecraft. The overwhelming success of these two Randsats, demonstrated Llimugli 
hundreds of experimental programs, has motivated NASA to continue to improve the Earth 
Resources satellite program. The third satellite, Landsat C, has been procured and is stdn'tluh d 
for launch in late 1977. This third satellite will carry a modified Multispcctrul rtcuimcr uiul 
W’ill utilize an improved digital ground system. NASA is now planning for the next si?]r Landsat 
D, which will provide several major advances, Landsat D will incorporate the Thematic 
Mapper (TM) as a new sensor, it w'ill utilize the .Multi-mission .Modular Spacecraft (MMS), 
it will make use of the Tracldng and Data Relay Satellite System (TDRSS) and it wall employ 
a new’ more advanced ground system. Each of these represent significant improvements in 
the state-of-the-art. This study is one of several which address various aspects of the planiR'd 
Landsat D system. 

As the Earth Resources Program has matured through the Landsat spacecraft it has bcgim 
the transition from an experimental research activity to a sound demonstration of proven 
utility. This important transition will be completed with the Landsat D system wiiich in- 
corporates several key improvements over the current system. These improvements, 
based on experience with the existing Landsats, will provide new capabilities in the space- 
craft, the sensor, the ground system, and the overall system design. These system 


1-1 



capabilities - which emphasize improved vegetation analysis, prompt availability of data, 
frequent coverage, and precise data registration and overlay for better change detection 
will permit the Landsat D to capture already proven economic benefits in such diverse 
applications as: 

• Monitoring world-wide food productivity 

• Mapping agricultural land use 

• Monitoring rangelands 

• Surv 63 dng for^^st resources 

• Managing critical watersheds 

• Detecting land use changes 

• Oil/mineral exploration 

An artist's concept of the Landsat D system is shown in Figure 1-1. The spacecraft will be 
based on NASA’s new Multi-mission Modular Spacecraft (MMS) and will operate two remote 
sensing instruments; a Thematic Mapper (TM), with 30 meter ground resolution, and a 
Multispectral Scanner (MSS), with 80 meter resolution. The system provides two data 
communication paths to the Earth; one is a direct readout link for ground stations (both 


Figure 1-1. Landsat D ^stem 
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domestic and foreign) within range of the spacecraft, and the other is a relay link via the 
Tracking and Data Relay Satellite System (TDRSS) for nearly full global coverage. The 
spacecraft will be in a sun-synclmonous orbit with a descending node time of 9:30 AM 
(similar to current Landsats). The orbital altitude and inclination will provide near global 
coverage of the land and near coastal regions with a repeat cycle every 16 to 18 days. 

The use of the new MMS spacecraft as the basic bus mil provide both improved sensor point- 
ing accuracy (±0.01 degree) and stability (10“'^ degrees /second). These impi’ovemeiits will 
manifest themselves in more accurate and more straightforward geometric corrections of 
the image data; both relative (image to image) and absolute (with respect to the Earth's suri;u-el. 
The MMS incorporates modular subsystems in tlie key areas of power, attitude control, and 
command and data handling. This modularity together with the compatibility for both conven- 
tional and Space Shuttle launches will enable in-orbit repair and refurbishment of the spacecraft. 

The Thematic Mapper, TM, is an evolutionary improvement of the MSS and provides several 
significant capabilities. The spatial resolution on the ground has been reduced to 30 meters 
(compared to 80 for the MSS) which will allow radiances to be me asured for areas (pixels) 
less than one sixth the size as for the MSS. The TM will incorporate six spectral bands 
(and have the capability for a seventh) which have been located primarily on the basis of 
their ability to discriminate vegetation (a fundamental application of remote sensing). In 
addition the radiometric sensitivity of the TM has been improved by reducing the signal-to- 
noise characteristic and increasing the levels of digital quantization. These sensor changes 
combine to cause the TM to have a data rate of 120 Mbps, (an order of magnitude increase 
over the 15 Mbps of the MSS) . 

For remotely sensed multispectral data to* be truly practical for many potential operational 
users (agricultural analysts, hydrologists, etc.) it must be received by them in usable 
form within 48 to 06 hours after imaging. Promptness in receiving data products is one of 
the most critical aspects of the Landsat System. 

The Landsat D System will be thoroughly integrated with the needs of operational users. It 
mil include improved preprocessing of all data, central data processing, archiving and retrieval. 
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low-c'ost receiving and data centers for large volume users (such as the U. S, Department 
of Agriculture) and provide maximum efficiency and economy in utilization by state, regional, 
and foreign users. Featuring the rapid electronic transmission of all data, the Landsat D 
system will reduce the time between satellite imaging and user reception of data to the 
required 48 to 96 hours. 

As illustrated in the artist’s concept the system provides two daia linl<s to the ground. The 
first link, for both MSS and Thematic Mapper data, is directly from the satellite to domestic 
and foreign ground stations as the satellite passes through their reception areas. The 
second link is via the Tracking and Data Relay Satellite System (TDRSS). As shown, the 
data is transmitted to a TDRSS satellite, in stationary orbit, and relayed to the TDRSS 
receiving station. The TDRSS receiving station transmits the data via a domestic communi- 
cations satellite to a central data processing facility that, in turn, relays the data to any local 
data distribution center equipped to receive it. Tliis linlc, vda TDRSS and the comnuinicalion 
satellite, will thus have global acquisition and relay capabilities, providing rapid access 

to Thematic Mapper data for users throughout tlie world. Both data links have a planned 
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maximum data capability of 135 Mb/second at a 10 bit error rate. 

The Landsat D system described is currently in the planning stages by NASA. As part of 
the planning for this future system, NASA has undertaken a series of studies, v\lth Gener-al 
Electric and others, to investigate various system options. This particular study (the 5th 
in the list) is one of seven conducted by Genex'al Electric to exiilore different aspects of the 
total ground system thai will be required by Landsat D in order to meet the overall mission 
objectives. 

The seven ground system studies are: 

1. Local User Terminal Study - an investigation into the requirements and 
options available for direct readout (primarily foreign gTomid stations) 
of Landsat D data, 

2. User Data Px-ocessing Study - an effort to estimate tlxe scope, size, and 

cost of the major user data processing system requirements. 
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3. Data Processing Facility Study - a requirement and sizing study to provide 

preliminary estimates of the scope and cost of NASA's central Landsat D 
data processing center. 

4. GSFC Research & Development Study - a survey and analysis of the functions 
and facility required of NASA, to continue the basic research on spacebome 
remote sensing and its applications. 

5. Operations Control Study - an analysis of the modifications necessary to upgrade 
or mod’Tv the NASA Operations Control Center (OCC) for Landsat D, 

6 . Data Transmission and Dissemination Study - an investigation into the options 
and limitations of various data communication alternatives including centraliza- 
tion versus decentralization, 

7. Position Determination and Correction Study - - an analysis of the impact and 
alternatives afforded by the MMS spacecraft of Landsat D on image geometric 
correction. 


1.2 THE LANDSAT D CaaOUND SYSTEM 

A top-level functional diagram of the Landsat D ground system is presented in Figure 1-2. 
The six major subsystems included are the Data Input Subsystem (DIS), the Central Data 
Processing Facility (CDPF), the Product Generation and Dissemination Facility (PGDF), 
the Data Management Subsystem (DMS), the Agriculture Utilization Subsystem (AUS), and 
the Applications Development Laboratory (ADL). Each of these subsystems is briefly 
described below. 



. SAMPIC SLUIErirS 
, ApmGtOA'tmiCCOKHtCTIONS 
. ACCEPT NON Ifo DATA 
. GENERATE CROP PRODUCTION ESTIMATES 

Figure 1-2. Ground System Concept 
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The Data Input Subsystem piS) receives 120-135 Mbps data from the TDRSS via dedicated 
cable interconnection. The prime functions of the DIS are to record the raw input data, to 
perform cloud cover detection and scene .editing, and to compute geometric correction 
matrices on a per swath basis. 

The Central Data Processing Facility (CDPF) receives edited data from the DIS and performs 
standard operations to all data. These operations include radiometric correction and data 
reformattii^ to a band-interleaved-hy-Iine (BIL) format. 

The Product Generation and Dissemination Facility (PGDF) is the main interface between the 
Landsat D ground system and general users. TMs facility provides Landsat D data, in either 
digital tape or film format, to users on demand. The data, which may be geometii.cally 
corrected to various map projection systems or enhanced as requested by the user, is avail- 
able in a variety of sizes, formats and media. The PDGF also houses and manages the 
system archive. 

The Data Management Subsystem pMS) provides the central point of control and data base 
management for the Landsat D ground system. Its prime fimctions include management of 
user demand, the system arclhve, system communications and system redundancy. The 
DMS also maintains system status, production statistics, operations logs and administrative 
services. 

The Agriculture Utilization Subsystem (AUS) receives data directly from the CDPF and 
performs those operations necessary to produce world crop production forecasts on a 
periodic basis. The operations to be performed include geometric correction, sample 
segment extraction, multispectral analysis and areal and statistical analyses. It is in- 
cluded here as part of the ground system because it represents the first major user of Landsat 
D data. 


The Applications Development Laboratory is the main R&D facility dedicated to the appli- 
cations of TM data. The facility is equipped to receive, store and handle TM and 
supportive data and conduct analyses in pursuit of quasi-operational applications technolo^ 
development. A primary goal will be the development of crop yield technology that models 
TM and supportive data to produce crop yield forecasts. 

1.3 OPERATIONS CONTROL CENTER (OCC) 

Tlie Operations Control Center (OCC) performs the functions required to operate and 
evaluate the spacecraft as well as to manage payload data operations. The OCC provides 
the command and control feedback to the spacecraft for accomplishing specific payload 
data collection requirements. 

The original intent of this study was to provide a workable design and cost estimate for an 
OCC that would meet the requirements of the Landsat-D system. Since this design was 
based on maximum utilization of available hardware and software, the applicable design 
elements of the present Landsat 1 and 2 OCC were employed whenever feasible. The results 
of this study are contained in Section 2 of this Final Report. 

A modification was made to the original study contract (reported in Section 2) to 
investigate the compatibility of the Landsat-D OCC with the Payload Operr-tions Control 
Center Network (POCCNET) concept. A specific goal of this portion of the study was to 
identify any adverse mission unique .requirements that the Landsat-D system placed on 
POCCNET. The conclusions of this area of the study are: 

1, All Landsat-D OCC requirements are met by the POCCNET concept. 

2, POCCNET features enhance the Landsat-DOCC operation, 

3, The Landsa1>D OCC is not dependent upon POCCNET implementation. 

The results of this Final Report associated with this Investigation are reported in Section 3. 

It must be noted that this study should not be considered a Multi-Mission Modular 
Spacecraft (MMS) OCC design. The detailed requirements for operation, software modi- 
fication, command management, etc. , for the MMS have not been included in the 
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considerations outlined below. Further, the interface and equipment requirements were 
enumerated, but largely not specified or characterized in detail. 

Thus, this OCC Final Report covers two OCC efforts; 

1. Design and cost a baseline OCC system based heavily on the current Landsat 1 
and 2, (See Section 2). 

2, Assess the compatibility of that OCC with the POCCNET concept {see Section 3). 

This report does not address the detailed design of a POCCNET based OCC for Landsat-D 
nor does it provide cost estimates for such a design. Further, several aspects of the 
MMS based Landsat-D are not included due to study scope limitations; although these 
omissions are important for completeness. Their impact on the basic conclusions is felt 
to be negligible. 
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SECTION 2 


BASIC OCC STUDY (WITHOUT POCCNET) 

As discussed in the Preface, this OCC Fiual Report has been divided into two relatively ’'stand- 
alone" sections. This Section 2 discusses the original study effort wMch was aimed at producing 
a baseline OCC design and cost estimate for Landsat-D. The results of a study contract modi- 
fication which included the investigation c£ POCCNET are reported in Section 3 of this report. 

Because of the "stand-alone" nature of Sections 2 and 3 there is some redundancy of material 
between the two sections. Those sections which are redundant have been marked with an asterisk 
(*) following the title. 

2.1 OCC REQUIREMENTS 

The OCC has three major areas of responsibility in the performance of its functions. 

These are: 

1. Data Management 

2. Plight Operations Command 

3. Spacecraft and payload performance evaluation 

Figure 2-1 illustrates the Landsat-D functional interfaces required to perform these functions. 


2.1.1 DATA MANAGEMENT GROUP (DMG)=^ 

Planning and scheduling functions which define the spacecraft and ground activities 
necessary to effectively satisfy the mission and flight operation requirements are performed 
by the Data Management Group (DMG). The plans and schedules must be based upon sensor 
coverage requirements, spacecraft and payload configuration, network availability, and 
environmental constraints. The resultant activity plan is a time-ordered list of spacecraft, 
payload, and network events. 
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Figure 2-1. Landsat-D Functional Interfaces " 
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The planning and scheduling responsibilities of DMG cover all elements of the operational 
mission system and must be designed to make the most effective use of the resources of tliat 
system. 


2. 1.1.1 Sensor Coverage Requirements * 

The Data Management Group has the responsibility of receiving requests for Payload Data 
from the NASA Data Utilization Office, the Landsat Project Office, and some special 
users and mtegrating them into the sclieduling data base. This data base is used to 
schedule the on-board payload as well as provide management reports containing, but not 
restricted to the following information. 

a. All outstanding requests for Landsat images. 

b. All satisfied requests for Landsat images and the assessment of each image, 

c. All in-process requests and their state of completion. 

The maintenance of this data base requires feedbaclc from the CDPF on the status of all 
in-process payload data. 

2. 1.1.2 Spacecraft and Payload Configuration * 

Spacecraft and payload configuration must be considered in the development of the activity 
plan in order to ensure that the current resources of the spacecraft are effectively 
utilized. Changes in the status or operability of the spacecraft or payload must be identi- 
fied and input to the activity planning function in order to prevent any compromise to 
spacecraft health and safety. 

2. 1.1.3 Network Availability-^ '- 

Network availability must be determined for emergency contact operations as well as 
tracking. Tracking requirements will be input to DMG by the NASA Orbit Determination 
Group and will define requirements for both routine tracking and special tracking for 
orbit adjust maneuvers. Orbit adjust requirements will be determined by the Flight 
Dynamics Group (FDG) and input to the DMG. The DMG must factor these requirements into 
the activity plan. The DMG must coordinate all network support requirements with STDN 
and be capable of iterating the activity plan as a result of network schedule conflicts. 


2-3 


In addition, the DMG must maintain a constant availability status with the Tracking and . 
Data Relay Satellite System (TDRSS). All data collection (other than Direct Readout) 
and tracldng will normally be performed through the TDRSS system 

2 . 1 . 1 . 4 Rnyironmental Constraints* 

Environmental constraints include tliose factors wlaich affect or restrict payload operations 
such as sun angle and weather. 

2. 1.1.5 Spacecraft Location and Attitude Data Processing * 

The CDPF requires spacecraft location and attitude data to correctly process the payload 
saisor data, The spacecraft attitude data is extracted from the spacecraft telemetry 
data by die OCC and is condensed with location data supplied by the Orbit Determination 
Group. This data is then transferred to the CDPF for use in payload data processing. 

2.1.2 FLIGH T OPERATIONS CONTROL* 

The OCC is the focal point for Landsat^D in-orbit operations. The OCC operations control 
function must, tiierefore, be capable of integrating and directing both the internal OCC 
activities and the external network support activities to ensure execution of the activity 
plan provided by the OCC schediding function. The operations control function must also 
be capable of rapid and effective response to contingencies in both the spacecraft and 
ground support systems. 

The internal OCC activities associated with the OCC operations control functions include 
spacecraft command generation, transmission, and verification; real-time spacecraft 
and payload performance evaluation; payload data reception and recording: and coordination 
of the associated OCC computing support. 

These internal activities must also be coordinated with the scheduled network support 
activities in order to maximize tlie effectiveness of the OCC operations. 

2.1.2, 1 Spacecraft Command Generation, Transmission and Verification * 

The OCC is required to genex’ate the commands necessary to operate the spacecraft and 
its payload. Command generation responsibility include: 
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X. Compilation of commands which satisfy the activity plan and spacecraft system 
performance and configuration requirements. 

2. Display and verification of commands prior to transmission to ensure that the 
command list is correct and does not violate prescribed operational 
procedures. 

3. Blocking and formatting of commands and transmission via the appropriate 
support network. 

4. Verification of command execution in the spacecraft for both real-time and 
stored program commands. 



The OCC is responsible for the analysis and evaluation of spacecraft and payload data to 
determine tlieir configimation, health, and performance at both a system and subsystem 
level. Real-time processing and analysis are required to pennit on-line conmiand and 
control over the spacecraft. Implicit within tliis requirement is die fact that the OCC 
must be capable of receiving, processing, displaying, distributing, and storing the 
spacecraft data necessary to fulfill these responsibilities. 

2. 1.2. 3 Payload Data Reception * 

The CDPF/DIS is the focal point for the reception of the payload data. The data will be 
transmitted from die TDRSS ground station to GSFC via the DOMSAT relay. The OCC 
will record incoming payload data for a "Quick Look" display. 

2. 1.2. 4 OCC Computing Support Coordination 

The OCC operations control function also coordinates the OCC associated computing 
support to provide maxim mn support not only to the on-line flight operations but to the 
other OCC functions as well. 

2. 1.3 SPACECRAFT AND PAYLOAD PERFORMANCE EVALUATION'-f 
The OCC is responsible not only for the short-teinn spacecraft configuration and health, 
but also for long-term trend analysis, investigation of anomalies, and for the historical 
reporting of spacecraft and payload performance. The performance evaluation function 
uses all available sources (telemetry and video data, strip chart records, system scheduler 
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outputs, etc.) to analyze the spacecraft and payload performance on an in-depth, long- 
term basis and to investigate anomalies in the spacecraft and payload systems. 

Periodic reports are generated to disseminate information on die spacecraft and payload 
performance. 

2.?. QCC SYSTEM DESIGN 

Tlie three major functional requirements of the OCC are satisfied by the following eight 
major subsystems: 

1. PCM Data Processing 

2. Image Data Processing and Display 

3. Command Generation 

4. Communications and Data Distribution 

5. Status Data Control and Display 

6. System Scheduling 

7. Computing Services 

8. OCC Software 

Each of these subsystems is described in the paragraphs below. 


2.2.1 PCM DATA PROCESSING SUBSYSTEM 

The PCM Data Processing Subsystem, performs the functions required by the OCC for 
the processing, analysis, and evaluation of the spacecraft telemetry data. Tliis sub- 
system consists primarily of telemetry processing applications software operating witliin 
the OCC computer. The PCM Data Processing Subsystem operates on both real-time and 
play-back telemetry data and consists of tliree software elements. 

1. D ecomm utati on S of twar e. Decommutates all spacecraft telemetry data input 

to the OCC and prepares it for analog and digital displays and further computer 
processing. 

2. On-Line Processing and Analysis Software . Processes all decommutated 
spacecraft telemetry for real-time display and evaluation and prepares the 
data for off-line processing, 

3. Off-Line Processing and Analysis Software. Processes spacecraft 
telemetry data for in-depth evaluation of system and subsystem performance. 
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2.2. 1.1 Decommutatlon Software 

The Decomrautation Software operates in the OCC communications processor, which is 
part of the OCC Computing Services Subsystem described in Section 2.2.7. All spacecraft 
telemetry data received at the OCC is input to the communications processor and is 
operated on by the Decommutation Software. 


The real-time data is input to the De commutation Software in block 
format. The software performs the processing necessary to establish frame, subframe, 
and word sync, and then transfers the data, one major frame at a time, to the On-Line 
Processor and Analysis Software operating in the OCC computer. The Decommutation 
Software also extracts selected words from the decommutated data and formats and 
outputs these for display at strip chart and event recorders. The selection of these 
words and their routing is controlled by distribution tables input by the operator or by 
the OCC computer. 

The software first verifies the NASCOM header data to insure that this block contains 
telemetry data intended for the OCC. (Inputs other dian telemetry and other predefined 
data will be ignored by the Decommutation Software), It then examines tlie 36 flag bits 
to determine whether any command status information is present. These bits are gene- 
rated by the command equipment at the remote site and inserted into the telemetry data 
blocks. The command status information provides a near real-time indication of the 
status of commands transmitted from the OCC. The flag bits are encoded to identify 
the command number, the go/no-go results of the polynominal decoding and RF echo check, 
and the time of transmission (minute and second) ficom the remote station. 

2 . 2 . 1 . 2 On-Line Processing an d A -al:; sis Sofhvare 

The On-Line Processing and Analysis Software (ONPAS) runs in the OCC computer and 
operates in conjunction with hie Decommutation Software. ONPAS accepts and processes 
decommutated real-time data, and performs the frame-by-frame processing functions. 

The on-line software also generates a raw data file containing the real-time telemetry 
data. 
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The ONPAS system consists of a number of Telemetry Processing Packages, designed to 
perfrom the following six fimctions: 

1. Reformatting . Basically a data unpacldng and reordering function. 

2. Range Check . Fitting analog values into various size "bins”, 

3. Status Determination . Verification of the necessary indicators 
of spacecraft status. 

4. Calibration . Each telemetry sample is converted to engineei'ing 
units by means of stored look-up tables. 

5. Pseudo- Function Generator . Additional spacecraft performance 
measures, such as operating efficiencies, power outputs, etc. 
wMch are computed from the telemetry data are generated. 

6. Smootlnng . Transient noise is removed from the telemetry data 
prior to further processing. 

2.2. 1.3 Off-Line Processing and Analysis Software 

The Off-Line Processing and Analysis Software (OFPAS) accepts telemetry data, via the 
RDT (Raw Data Tape) , and performs the in-depth processing required for detailed evaluation 
of system and subsystem performance. OFPAS also creates the spacecraft location attitude 
tape (SLAT) or file for use by the Central Data Processing Facility (CDPF) . 

OFPAS operates in either a batch or multi-processing mode and, like its on-line coimter 
part, consists of five individual processing paclmges operating under the control of the 
Off-Line Supervisor (OLS). OLS establishes the processing order, controls the linlcages, 
and brings in the data from data base. Off-Line packages each process all of the data 
on a frame-by-frame basis and collect the necessary information from each frame as 
required. When the last frame has been processed, the statistical and other calculations 
are made and the results compiled for display by the display software. With the exception 
of tiie Generalized Statistics Routine (GSR), the processing packages may be run in any 
order. The GSR computes the minimum, maximum, mean and standard deviation 
unconditionally for a function over the entire orbit span and/or may be computed on an 
operating mode basis. GSR computes statistics for subsequent display, trend plotting, 
historical archiving, and for use by the other OFPAS processing packages. 
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The remaining processing packages operate on and compute data for the analysis of 
specific spacecraft functions or subsystems, as their titles imply. At the conclusion 
of this processing the OLS compiles the results of these individual processing functions 
and wraps up flie off-line processing by compiling the data to be plotted on the OCC plotter. 
The plot data is generated by the GSR and the other processing packages of OFPAS. The 
plot data comriled by OLS is transferred to the display software where it is formatted 
into magnetic tape for aitput to the plotter. 

2.2.2 IMAGE DATA PROG ESSING AND DISPLAY ^ 

The Image Data Processing and Display Subsystem in the OCC provides the ability to 
monitor sensor operation during real-time NTTF station contact. This capability will 
allow real-time evaluation of payload operation and response to command. 

Evaluation of the performance of the spaceborne payloads will be based on the utilization 
of three data sources. 

1. Quick Look video display from the OCC Image Data Processing and Display 
Subsystem. 

2. Narrowband PCM Telemetry Data from Payload Telemetry Points processed 
by the OCC PCM Processing Subsvstem. 

3. High quality' imagery generated by the CDPF Image Processing Subsystem. 

The following paragraphs describe how each of the data sources will be utilized to provide 
maximum confidence in payload status, health and performance. 

2.2,2. 1 Evaluation Using Quick Look Display * 

One of the most effective supervisory tools for assessing sensor performance is the 
formed image from the sensor itself. Unfortunately, the types of sensors used feature 
a low line rate video and do not lend themselves to a real-tUne display. Expedients, 
such as open lens camera attachments must be used to circumvent the inability of the human, 
eye to integrate tlie slow scan signal and permit evaluation of the quality of the image and, 
therefore, senror performance. 

A camera, most conveniently a Polaroid system camera, coupled to a CRT display, can 
provide tlie integration of die data into picture information for evaluation by the human 
eye. Unfortunately, the time elapsed fr’om the initial signal arrival to that of a completed 
picture is significant, but it is nearest to real-time evaluation of a full coherent frame. 


Because a picture frijrae is composed of individual "lines" of electrical signals assembled 
on a basis of synchronii ing signals, a correctly appearing picture will assure the super- 
visory personnel of propei operation of the camera. Any other displeasing effect in the 
obtained pictures is indicative u' g fficulties, A number of operational problems can be 
detected to some extent; 

1. Geometric distortion (large percentages only). 

2. Sync failures. 

3. Line dropouts. 

4. Interference of various kinds. 

5. Calibration signal status. 

6. Gray scale calibration (if provided in the sensor). 

Other problems more or less obvious,, but quite evident, to an experienced sensor per- 
formance evaluator can also be detected. 


The second supervisory tool is certainly an on-line oscilloscope display, set up to show 
on its CRT screen the indi vidual incoming signals. Based on familiarity with "good" 
signals, the anomalous signals can be easily spotted. Nevertheless, once the 
oscilloscope display shows defective signals, the hard copy picture will also be 
improper. 

2. 2. 2. 2 Evaluation using PCM Telemetry Data " 

The second source of performance evaluation data is the processed sensor telemetry. 
Telemetry evaluation, in general, is simple once the past history of given equipment 
is known and familiarity with it exists. 

During the integration tests, strip charts of sensor telemetry are made on a routine 
basis. Telemetry and calibration compendiums are compiled and contain waveforms 
that appear under all possible modes of operation. Similarly, during the real time orbital 
operations, the strip chart recording is perfoi’ined for both real-time and off-line 
detection and analysis of abnormal conditions. 
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More comprehensive data describing the overall operation of the payloads is generated 
by the PCM processing software described in Section 2.2.1 , Hiis software processes the 
payload telemetry from the real-time data to produce a report of sensor performance 
which defines the operational profile of ail sensor activities. In addition, this data 
is used to compute statistical and trend data required for long term performance. 


2.2.2. 3 Evaluation Using CDPF Imagery * 

The evaluation described previously was concerned primarily witli the identification of 
anomalies in sensor performance which could endanger the spacecraft or impair the 
performance characteristics of the payload. Tliese factors cannot generally be detected 
at the quick look level of evaluation, but must be done from an examination of high quality 
images. 

The guidelines for evaluation will be firmly established once the real imagery from the 
respective sensors has become available and test and integration experience has been 
gained. 


2.2.3 COMMAND GENE RATION SUBSYSTE M 

The Command Generation Subsystem is designed to compile, format, transmit and verify 
spacecraft commands at the OCC. Commands are compiled in advance from the activLt;’ 
plan generated by the System Scheduling software (reference Section 2.2.6). During the 
real-time acquisition the command messages are formatted, verified, and transmitted 
under command operator control. All commands generated by the OCC are routed to 
the remote sites for RE transmission to the spacecraft. 


2.2.3. 1 Command Compilation Software (CCS)=^- 

The fvmction of the CCS is to translate desired spacecraft events, defined in the activities 
plan (generated by System Scheduling Software) into the appropriate spacecraft command 
sequences which will cause those events to occur. The CCS functions in the non real- 
time environment and provides no functions required during the on-line command 
transmission. 
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The input to the Command Compiler is the Activity Plan generated by the System Scheduling 
Software. This Activity Plan resides in the OCC computer and will be assessed at 
program execution time. For each event-listed in the Activity Plan, the CCS will generate 
the required command or sequence of commands to perform that event. The output of 
the Command Compiler will be a report which describes the spacecraft commands and 
their execution times. Commands which are to be executed within a predicted ET acqui- 
sition window will be formatted for transmission as real-time commands (ETC's). 
Commands which are to be executed outside a ET acquisition window will be formatted 
for transmission as stored commands. Critical commands included in the list will be 
flagged for the operator. 

2.2. 3.2 Command Management Software (CMS) =^ 

The CMS performs the processing required to transmit commands to the spacecraft under 
control of the command operator. This software is normally co-resident with the ONPAS 
of the PCM processing subsystem (Section 2.2. 1} and the Status Data Control and Display 
Subsystem software (section 2,2.5) and operates in conjunction with tins software. The 
CMS has the highest computer syst em priority in terms of central processor time, 
resource aEocation and report display processing. 


CMS operations are initiated for the most part by command operator inputs from his 
operations console. 

The preliminary command list resulting from the CMS is displayed for the command 
operator on request. The operator has the capability to edit, delete and insert both 
single commands and command sequences from the command console. 

At the conclusion of this process the complete command list is displayed for review and 
approval. The command list, with its sequence annotation, is stored within the OCC 
computer for subsequent caE-up by the CMS during the real-time acquisition period. 

2.2.4 COMMUNICATIONS AND DATA DISTEIBUTION SUBSYSTEM (C&DD)* 

The C&DD Subsystem configuration is shown in Figure 2-2, The C&DD Subsystem 
consists of the input/output signal conditioning and switching equipment, the OCC/CDPF 
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Figure 2-2, OCC Communications and Data Handling Distribution Subsystem* 












computer switching equipment, the timing equipment, the maintenance and operational 
consoles for the OCC, the voice communications equipment, the magnetic tape recorders, 
and the simulation equipment. The voice communications equipment is ejq^ected to be 
government furnished equipment, with the remaining portions of the subsystem furnished 
by the contractor. The C&DD Subsystem acquires data inputs, provides signal con- 
ditioning where necessary, and provides for the switching/patching and recording of PCM 
signal inputs, command outputs, timing signals, simulated PCM signals, and Computer 
Subsystem input/ output channels to the OCC Computer Subsystem and the Control and 
Display Subsystem, Coordination of OCC operations with the Landsat-D system is pro- 
vided by use of voice commmiication equipment. 

The C&DD Subsystem consists of several functional grot^JS of equipment. These groups 
are: 

1. Signal Conditioning and Switching (SCS) 

2 . Timing 

3. Computer Subsystem Switching (CSS) 

4. Maintenance and Operational (M&O) 

5. Voice Communications 

2. 2. 4.1 Signal Conditioning and Switching * 

The Signal Conditioning and Switching (SCS) equipment acquires data, provides signal 
conditioning where necessary, and provides for the switching and/or patching of PCM 
signal inputs, timing signals, simulated PCM signals, and command outputs to the 
magnetic recording equipment, the M&O console, the timing equipment, the Computer 
Subsystem and the Control and Display Subsystem, as required. The SCS will be 
remotely controlled from the M&O console described below. 

2. 2. 4.2 Timing * 

The timing equipment receives timing reference signals from the GSFC timing facility 
and from the Computer Subsystem. In addition, the timing equipment receives pass time 
SET/START/STOP/HOU3 commands from the Control and Display Subsystem. The 
formatted timing equipment outputs will be sent to the magnetic tape recording equipment, 
the Computer Subsystem, and to the Control and Display Subsystem for time correlation 
purposes. 
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2. 2. 4. 3 Computer Subsystem Switching * 

The Computer Subsystem Switching (CSS) equipment switches the OCC input/output 
signals within the OCC Computer Subsystem. Control of the CSS equipment will be 
r emoted to the M&O console. 


2.2. 4,4- Magnetic Tape Recording * 

The magnetic tape recording (MTR) equipment provides for the recording and reproducing 
of the PCM command and simulated PCM data from the signal conditioning and switching 
equipment, and the time code from the timing equipment. The MTR equipment will 
contain two recordiiig/reproducting imits. One unit will be used for normal operation, 
with the other unit available for backup capability. Monitoring and control of the 
recorder operation will be remote d to the M&O console. 


2.2. 4. 5 Maintenance and Operations Console * r 

The maintenance and operation (M&O) console will be used to control the OCC system 
configuration, to select the OCC data input, and to monitor the OCC system performance/ 
status. The M&O console operator will provide the interface between the operations 
supervisor and the NASA data handling and scheduling organizations. 

2.2. 4. 6 Voice Communications ^- 

The OCC voice circuits, associated hardware, and interfaces will be Government Furnished 
Equipment. Several operational positions will need Private Branch Exchanges (PBX), 

Switching Conference and Monitoring Arrangement (SCAMA), interfaces to remote ground 
networks, and Closed Circuit Loop (CCL) channels for GSFC internal communications. 

Installation l sets and communications panels will be accomplished under the 
auspices of the NASA Communications (NASCOM) organization at GSFC. Standard 
communications panels will be furnished to die designated operational and maintenance 
positions. For the most part, operational positions will use the standard communications 
panels, accommodating 30 or 60 pushbuttons. 
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2.2.5 STATUS DATA C ONTROL AND DISPLAY* 

The Status Data Control and Display Subsystem consists of the hardware and software 
necessary to present, maintain, and update the niission system and spacecraft system 
status data essential to flight operations. A block diagram of the subsystem is presented in 
Figure 2-3. The major components of this subsystem are: 

1. OCC operations consoles. 

2. Strip chart and event display recorders. 

3. Display control and report generation software which operates in the OCC 
computer. 


COMMAND OPERATOR 
CONSOLE 


OPERATIONS SUPERVISOR 
CONSOLE 



Figure 2-3. Control and Display Subsystem Bloclc Diagram* 


2-16 













2. 2. 5.1 Operations Consoles * 

Four consoles are required within the OCC OperatLons Control Room. The four consoles 
liave been identified as; 

1. Operations Supervisor (OS) consoles 

2. Command Console 

3. Spacecraft Evaluator Console (2) 

Hie OS console, Command console, and Spacecraft Evaluator Consoles will all have the 
same basic configuration. The addition of special panels and associated cabling to the 
basic configuration will produce the OS and Command consoles. Each console is equipped 
with a CRT display and a standard input keyboard and programmable function keys which 
permit access to die OCC computer. In addition, the consoles are equipped with a spacecraft 

time clock, GMT clock, pass time clock, communications panel, and a small matrix 
of status and alarm indicators driven by the computer which can be programmed 
according to each console’s function. Both the Command and OS consoles also contain 
a Command panel for the initiation of commands. This panel is provided at both con- 
soles for backup. The computer will only permit command inputs from one panel at 
any time. 

2. 2. 5. 2 Strip Chart and Event Recorders * 

The strip chart and event recorders provide the capability for displaying dynamic analog 
data in a more meaningful manner than the CRT's permit. This is especially true in die 
case of certain attitude control and other subsystem parameters. In addition, these 
recorders present the data in recognizable and repeatable patterns which can be readily 
interpreted as performance signatures from which anomalies are readily detectable. In 
othfflc* cases, these recorders serve as short term trend plots which, again, permit 
rapid identification of anomalies. 
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Under normal conditions the portable strip chart recorders and the event 
recorder will be located in the Operations Control room. Each of the strip chart recorders 
has the capability of displaying eight analog and eight discrete signals. The portable 
recorders are used in conjunction with spacecraft and payload evaluation functions con- 
ducted at the operations consoles. This arrangement affords full benefit from the multi- 
processing mode of the OCC computer system and the interactive capability of the con- 
soles. The system can operate on several processing requests simultaneously and can 
present the results of this processing to any of the appropriate devices. 

The strip chart and event recorders also serve as a critical backup display capability 
within the OCC. In the computer system configuration described in Section 2.2.6, 
these recorders are driven by the system's communication processor. Tliis processor 
is capable of operating in a stand-alone mode without benefit of the OCC central processor. 
In the event of CPU failure during real-time spacecraft operations, the communications 
processor would continue to present selected PCM data to these recorders, thus providing 
a significant backup PCM display capability for spacecraft evaluation. 


^•2*5. 3 Uisplay Control and Report Generation Software , 

Display generation and control within the Control and Display subsystem are performed 
primarily by two software packages, the Report Data Supervisor (RDS) and the Report 
Generator Supervisor (RGS). The purpose of the RDS is to collect the report information 
generated by the various telemetry processing and analysis packages, and control the 
flow of this information to operating system display and retention software. The RDS 
will also retrieve previously stored report information from the data base and make 
this information available to report generation software. 

The purpose of the Report Generation Supervisor (RGS) is to supervise the presentation 
of requested displays at the operations consoles by: 

1. Supervising the loading of the required Report Generator Packages (RGP). 

2. Requesting linkages to the required display data via the RDS. 
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Requests for displays and display options are communicated to the RGS via the System 
Request Executive (SRE). The SRE is described in Section 2. 2. 7,' These requests include 
new reports, page changes, page freeze/unfreeze and hard copy printouts. 

The Report Generator Pacltages will contain all of the formatting statements, device 
handler interfaces, and tabular and columnar information required to display tlie report 
information in a meaningful presentation at any of the operations consoles or printer. 

Figure 2-4 defines the information ©schange for this processing. 

Analog and digital PCM data, displayed on strip chart and event recorders located at 
the operations consoles, will be processed by the data decommutation section of the 
Decom program. 


Any CRT data set defined in the system can be displayed at any operations console. 
Requests for data set displays will be input to the system via the alphanumerical keyboard 
at that console. This display set request will be processed by the Systems Request 
Executive which will load the requested display set table and communicate it to the RGS. 
The RGS will then use the new display set table for the requesting console to extract and 



2-19 


Data required for trend analysis will be extracted post-pass from the telemetry 
file for this orbit. This data will be extracted, converted, and formatted in the codes 
appropriate for input to a stand-alone plotting device. The software required to do the 
extraction, formatting, and conversion is the Plot Data Pormatter (PDF), This program 
will run under control of the Off-Line Supervisor in the post-pass environment. 


2.2.6 SYSTEM SCHEDULING SUBSYSTEM* 

The System Scheduling Subsystem defines the scheduling of sensor operations that will 
effectively use the data collection capability of the spaceborne observation system, and 
the scheduling of necessary ground system support operations such as tracldng, orbit 
maintenance and ground station contacts. 

System Scheduling generates an overall system activity plan based on coverage require- 
ments, spacecraft and payload status, network availability, and environmental constraints. 
The activity plan produced must be a time-ordered list of spacecraft, payload and network 
events that do not violate any operational constraint imposed on the Landsat system. 

The subsystem is primarily a non real-time, data-base oriented, software system. 

The System Scheduling Subsystem provides the mission planner with a computational 
and booldceeping aid to assist him in the selection of a specific mission profile which 
efficiently uses Uie data collection capability of the Landsat system. 

The requirement to incorporate timely weather predictions compounds the problem of 
selecting an effective system schedule by minimizing the time available between receipt 
of weather predictions and generation of commands. Thus, the problem is to determine 
an efficient system schedule without violating any operational, expendable, or environ- 
mental constraint within a limited computation time. 

The subsystem represents a computer-aided approach to the system scheduling problem 
that facilitates the generation of overall system schedules witliin all of tlie aforementioned 
constraints. The key feature of the system is that it is computer-aided; e.g. , the OCC 
computer is utilized to perform routine arithmetic data processing, and to report constraint 
conflicts identified by the computer. In all cases, manual intervention can override 
computer generated decisions. 
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2*2.7 COMPUTING SERVICES SUBSYSTEM 

The Computing Services Subsystem must provide tiie data processing hardware and 
software capabilities to meet die fimction requirements described in Section 2,2.1 
through 2.2.G. In addition, it must provide; 

« A baclcup capability for on~pass commanding. 

• Test, diagnostic and simulation capabilities for all interfaces. 

• Standard software development and maintenance capabilities, 
e A graceful recovery capability for on-pass crashes 

2.2. 7.1 Software Requirements 

The OCC Software requirements reflect tlie processing and computation requirements 
resulting from the functional design of tlie OCC. These x'equirements can be divided 
into four major areas; 

1. Mssion Planning and Operations Scheduling 

2 . C ommand Generation 

3. Spacecraft Evaluation and Managenent 

4. Operational Control 

In addition to these four ftmctionai software requirements, there exists tlie requirement 
for a Data Base Generation and Maintenance ^stem. The Data Base will serve as the 
repository for spacecraft engineering data and mission system data, as well as that 
iif ormation generated by one or more of the functional entities (e. g. , data generated 
by the Mission Planning and Operations Schedule Module}, 

2. 2. 7. 2 Computer Requirements 

The OCC Computer System is designed to satisfy all of the processing and computation 
requirements wliich result from the OCC fimctional design. The OCC is divided into 
four major areas of functional responsibility: 

1. Mission Planning and Operations Scheduling 

2. Command Generation 

3. Spacecraft Evaluation and Management 

4. Operations Control 
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Mission Planning and Operations Scheduling involves the development of time sequenced 
activity plans for sensor, spacecraft, and ground system operations. Command genera- 
tion converts these activity plans into spacecraft recognizable command messages which 
are compatible witli the established command lihl^ transmission facilities. Spacecraft 
Evaluation and Management uses PCM telemetry data as its principal input in perform- 
ing both on-line and off-line analysis of the spacecraft status, configuration, perfor- 
mance and health. Lastly, Operations Control provides direction and monitoring of the 
OCC itself, and of the supporting elements. 

The processing and computational requirements of tlie OCC fall into several categories, 
many of which can be satisfied by the capabilities of a tliird generation, general purpose 
computer system. Mission Planning and Operations scheduling are performed by 
applications software paclmges operatmg in a nonreal-time batch or time-sliared mode. 
Tlie algoritlimic operations to be performed include event prioritization, scheduling, 
expendables management, and some ephemeris computations. 

Command generation requires both an interactive user mode and a semi-dedicated, 
real-time operations mode, Tlie interactive mode permits the applications software to 
operate effectively through the iterative steps required to develop and display the time 
sequenced spacecraft command list. These commands will then be processed and for- 
matted for output to the spacecraft in real-time via the NASCOM up-linlc. Tliis aspect 
of command generation requires specialized software and Iiardware interfaces witliin the 

OCC in order to utilize tlie existing NASCOM up-linlc facilities. 


Tlie Spacecraft Evaluation and Management function is perhaps the most demanding in 
terms of computer system requirements. Tiiis results from die fact tliat considerable 
specialized liardware is required, and the various applications programs must operate 
in real-time, Tiatch, and time-shared modes. Further, a flexible, efficient capability 
for the display of results must be provided. 

Operations Control imposes few unique requirements beyond those already described. 

In general, the requirements of this function have already been integrated with, and are 
fulfilled by, the other functions. Exceptions to this are Operations Control applications 
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software programs which will be satisfied by the computer configuration to be specified. 


The computer system concept, provides the necessary operating environments required 
of the applications programs, with special emphasis on the use of CRT displays with in- 
put keyboards to satisfy the need for effective display in real-time and user interaction 
in the time-shared mode. A mass memory device provides an efficient mechanism for 
rapid storage and retiievai of large amounts of often used information which comprises 
a significant percentage of the integrated OCC data base, and in conjunction -with the 
operating system and applications programs, affords an effective means for inter pro- 
gram transfers. Tapes provide media for mass memory purging, program storage, 
arolnving of OCC data, CDPF interface, and plotter interface. 

Special mention should be given to telemetry data acquisition and processing in the OCC 
computer. Spacecraft telemetry data is the primary input to this computer. This data 
can exist in several modes and formats at different rates, and can be input via any one 
of several media at one time. The computer system must be capable of providing the 
necessary interfaces with the equipments supplying the input data. In addition, the com- 
puter system must provide an effective means by which the telemetry processing appli- 
cations software can accept sync, verify, lock, decommutate, and distribute the tele- 
metry data to the various analog and digital displays to be employed. It is important to 
note further that this processing could occur in either a central processor unit, or in 
some form of programmable communications processor which functions as an integral 
part of the main computer system. 3h this later configuration, the preprocessor should 
be capable of stand-along operation in the event of OCC-PCU failure in order to main- 
tain analog display output. 

2.2, 7. 3 Communications Processor 

The OCC Computing Services Subsystem is required to satisfy a variety of interfaces, 
Tlie characteristics of these interfaces and the underlying requirement for operational 
reliabilify were the driving factors In establisMng the Interface equipment and configura- 
tion. 

The principal interface considered was that for die telemetry data. This data will arrive 
at the OCC in NASCOM blocIvS and data rates of 56 or 112 kbps via the NASCOM 494 
com nmnications processor. 
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2.2. 7. 4 OCC/CDPF Computer Interface Study 

This study was directed at determining the need for, or desirability, of a direct 
interface between the OCC and CDPF computers. Tlie primary purpose of this inter- 
face would be to permit the transfer of telemetry, ephemeris, and payload operations 
data from the OCC to tlie CDPF without the need for magnetic tapes, and would also 
facilitate QDC access to the CDPF image assessment information. 


The results of the study concluded the following: 

1. Direct interfaces between tlie OCC and CDPF computers are 
possible, and would probably malce use of a shared memory 
configuration. The cost and complexity of such a system 
would suffer a marked increase, however, in terms of both 
hardware and software, and would be accompanied by a 
decrease in reliability as compared to the basic configuration. 
It also becomes apparent tliat such an interface would not 
appreciably increase the capability of the overall system, 

2. The use of a shared disk-pack between the OCC and NDPF 

computers is available at little or no increase in cost and 
complexity. A read/write capability on the OCC side and a 
read-only capability on the CDPF side would provide the 
necessary interface for the direct transfer of spacecraTt 
location and attitude data from the OCC to the CDPF com- 
puter. This would eliminate most of the magnetic tape 
transfer interface presently used. 


2,2.8 OCC SOFTWARE 

OCC software required for PCM Data Processing is disucssed in Section 2.2.1, for 
Command Generation in Section 2,2.3, and for Status Control and Display in Section 2.2.5. 

This section discusses the other OCC sofhvare study activities in the areas of; 

1. Applications executive 

2. Data base generation and maintenance 

3. Test, diagnostics and simulations 
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2,2. 8.1 Applications Executive Software 

Applications executive software is defined as specialized applications paclca^ s designed 
to establish effective and efficient interfaces between the computer operating system and 
the scientific subsystem software. Detailed design of this sofhvare must, of course, be 
the complete definition of the selected computer system operating software, but three areas 
of applications executive software have been identified; 

1, Operating system interface software 

2, system interface control software 

3, System request executive software 

The first two of these areas are generally concerned \vith the routine interfaces between 
the vendor system and the applications software. This involves such processes as a 
device handler interfaces, disc control interfaces, and operating connectors for chain 
and execute or overlap's. It will also include tlie necessary interfaces for CRT display 
control and certain of the keyboard interfacing functions, as well as the applications 
controls required between the main computer and communications processor. 


The third area of applications executive software is concerned primarily \vith control 
over the co-resident real-time applications software. Tlie applications e:®cuttve soft- 
v,-are required has been defined as the System Request Executive (SRE) . The SRE will 
interface with and control Che operation of: 

1. PCM Acquisition Supervisor (PAS) 

2. Off-Line Supervisor (OL^ 

3. Report Generation Supervisor (P.GS) 

4. Command System Supervisor (CSS) 

All of the above are described in the preceding sections. The SRE will define the 
interrupt priorities for system operation and "tvill schedule the execution of the software 
packages to satisfy requests for services by die PCM processing, command, and dis- 
play subsystems. 

The SRE will accept two basic fypes of requests for service. These request types am: 

1. Data initiated requests 

2 . Operations console initiated requests 
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Data initiated requests are generated by interrupts associated witli equipment ejd:emal 
to the CPU. The first of these is the interrupt associated with a complete frame of PCM 
data and signals its availability for processing. The second data initiated request is 
generated by an interrupt associated with command acceptance messages returning to 
the CPU from the NASCOM 494. 

Operations console initiated requests will be in the form of alphanumeric parameter 
strings and/or function key actuations. Each of these parameter strings will be decoded, 
validated and assigned a processing priority by the SHE. 

2. 2. 8. 2 Data Base Generation and Maintenance 

The OCC data base is that collection of mission/system information used and generated 
by the OCC applications software system. The data base contains two different classes 
of information. The first is tabular in nature and consists of spacecraft engineering data, 
mission system data, and other related data, which is required by the applications soft- 
ware packages. Tins data is characterized by the fact tliat it is essentially a priori in-- 
formation which remains constant or is modified infrequently after mission operations 

begin. The most frequent routine update cycle presently anticipated for data in this 
category is once per day for the input of new ephemeris and image assessment infor- 
mation for the System Scheduling Subsystem. 

The second class of information in the data base consists piimarily of information 
generated by one applications program for use by another, and/or by itself at a later 
time. The System Scheduling software, for example, generates an activity plan for 
events required during a particular hiture orbit, and places tliat plan in bull^ storage 
for retrieval later by tlie Command Generation software. Spacecraft evaluation soft- 
^vare generates performance reports after each orbit and outputs these reports to the 
data base for subsequent retrieval for trend analysis purposes. 

2.2. 8. 3 Test, Diagnostic, and Simulation Software 

Various forms of checkout software are required tlmoughout the implementation, integration, 
and operation of the OCC. These must satisfy the requirements for computer, system 
test and diagnosis , application software checkout, and network compatibility and con- 
figuration testing. 
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2.3 LANDSAT-D QCC DESIGN ALTERNATIONS 


This portion of the report examines the GCC design changes that would have to be incor- 
porated for the Landsat system. The results show that the current OCC design/archi- 
tecture can perform the Landsat~D/OCC mission with several software program additions 
as listed in Table 2-1. 


The current OCC design/architecture can accommodate these additions. 

The mix of FORTRAN to assembly language coded programs in the current OCC are 
shown in Table 2-2. There are five major categories of software programs: The System 
and real-time categories of programs are coded in assembly language and represent a 
significantly small number of programs with respect to the total program complement. 
Tho remaining on-line, off-line and mission/ pla.Tm.mg program categories are coded in 
FORTRAN. The systems programs were coded and supplied by Xerox as executive 
software. The remainder, results in only approximately 1 or 2 programs out of 64 
cfded in assembler. FORTRAN coded programs represent about 959f; of the software 
in the current OCC design. 
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TABLE 2-1. 


APPLICABILITY OF CURRENT OCC DESIGN /ARCHITECTURE TO LANDSAT D OCC 

1. Spacecraft Cofomaadrng • Software Add Anteima Pointing Commands {Acquisition-Re- 

acquisition) 

(TDRSS- Landsat-D + Landsat-D Sites) 

Add Thematic Commands 

Add Real time Commanding via TDRSS {Assume like 
STDN Commanding interface-blocked) 

Current Software package is applicable for STDN 

backup commanding 

Delete RBV control 

No on-board tape recording possible 

Change to 4800 Bit Block 

9 Hardware No change required (Assume 4800 Bit Block commanding) 

2. Telemetry Processing « Software Add monitoring for loss of lock (Ant. Ptg. ) 

Add Thematic Mapper Sensor Status Processing 
Drop RBV status processing and possibly 
on-board tape recording 

Current design - OK; with change in SgW, architecture 
due to Landsat D S/C H,W, changes. 

Change to 4800 Bit Block 

© Hardware No change required 

3. Sensor Scheduling/Planning © Software Add Sensor ON scheduling supplied by DME 

Add Sensor ON information in R/T to DME 

© Hardware Probably don’t need NOAA facsimile with P/L sensor 
gating done at Wliite Sands 

Add 4800/9600 baud hardware interface for OCC and 
CDPP 



TABLE 2-1 (cmTlNUED) 


Spacecraft Performance Data 

• Software 

Modify the SLAT program to provide CDPF S/C 
performance data. 


« Hardware 

No change required 

Spacecraft Evaluation 
and Management 

© Software 

Delete EBV processing, possibly no tape 
recording on-board 
Add TM processing 

Current design - OK; with change in S^Wo architecture 
due to Landsat D S/C Ho W, changes 


• Hardware 

No change required 

Status Control & Display 
Processing 

• Software 

Delete edit/review of PL scheduling data to CRT 
Add PL sensor scheduling received from CDPP 
Modify current displays for Landsat unique parameters 


9 Hardware 

No change required (See 3 above) 

NASCCM Scheduling/Literfaee 

© Software 

No change required 


© Hardware 

No change required 


Table 2-2. Current OCC Software 







WORDS 







CPU 


PROGRAM 


DISK STORAijE 


No. 

MEMORY 


CATEGORY 

No. PROGRAMS 

REQUIRED 

% ASSEMBLY 

OVERLAYS 

ALLOC. 

COMMENTS 

Real Time 

4 

412 Granules 

100 

0 

11,776 

SRE 




15 

11 

10,240 

DIS 




3 

3 

15,872 

CMD 




3 

6 

23,552 

PCM 

System 

46 

1530 Granules 

100 

Many 

19,968 

XDS supplied 

On-Line 

21 

619 Granules 

0 

* 

39,492 

*Only 1 Prog. 
Uses Overlays <2), 
Max Size 30,439 
Min Size 4,608 

Off-Line 

1 

420 Granules 

1 

14 

39,492 

Max only 37,000 
Min only 29, 813 

Mission Planning 

42 

1458 Granules 

0 

0 

39,492 



Max size 37,659 
Min size 4,339 


REMARKS: 


1 grandule 
1 word 
1 byte 


512 wox’ds 
4 bytes 
8 bits 



An issue to eonsider^ve and beyond the fact that the current OCC design/architecture 
is applicable to the Laiidsat-D OCC, is tliat the current OCC hardware is approximately 
six years old. As the Landsat-DOCC time period begins, the current OCC hardware 
\vill be approximately ten years old and presumably, will be expected to last another 
ten years. Together with the fact that the present equipment manufacturer has gone out 
of business/market and no longer supports his product are considerations for the 
replacement of the current OCC Iiardware for the Landsat-D OCC. Tlierefore, it is 
recommended tliat the equipment listed in Table 2-3 Current Hardware be replaced. 

It is realized that this impacts the software conversion from the Sigma to Brand "X". 
However, this is softened somewhat by the high percentage use of FORTRAN coded 
programs (95%). This assumes Brand "X” executive sofirware system can replace the 
current OCC executive software in capability since there are extensive real-time execu- 
tive software computer systems available. The conversion of FORTRAN programs in 
terms of complexity is a function of tire peculiarities of going from the Sigma to Brand 
"X" compilers and tire degree of in-line code (assembler) used. This is not, as it 
appears to be , a major problem. 

The conclusion reached is that the current OCC design/architecture is capable of per- 
forming the Landsat-D OCC mission wiflr the addition of several new software programs 
and the use of an additional modem hardware interface (OCC-CDPF). It is recommended 
that the current OCC hardware replacement talce place since the Landsat-D time period 
dates the current hardware by ten years which presumably must last for yet another ten 
years. This with the loss of manufacture/support are contributing factors. Software 
conversion of existing programs from the Sigma to Brand "X" is aided by the fact that 
approximately 95% of the OCC software is currently coded in FORTRAN. 

NOTE; The assumptions made for the purposes of tins report consist of; 

1. Single spacecraft operations 

2. Use of current OCC design/arcMtecture witli changes for Landsat-D 

3 . 1200 bit block upgraded to 4800 bit block and telemetry commanding 

4. TDRSS Serial data converted to 4800 bit block for OCC processing 
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TABLE 2-3 


CURRENT OCC HARDWARE 


1. NASG CM INTERFACE UNITS 

2. SIGNAL CONDITIONING AND SWITCHING 

-MTU/SCOPE PATCH PANELS (2 EA,) 

- BIT/5RAME/SQB FRAME SYNCHRONIZER 

- PCM SIMULATOR 

3. WIDE BAND DATA SET COUPLER (2) 

4. CONSOLES (6) 

- COMMUNICATIONS PANEL 

5. COMPUTER INTERFACE EQUIPMENT 

SIGMA 5 GROUND STATION TIME DIL (2) 
SIGMA 5 DIO DISTRIBUTOR (2) 

TIMING EQUIPMENT 
SIGMA 3 DIO DISTRIBUTOR (2) 

SIGMA 3 PCM INTERFACE (2) 

SIGMA 3 RECORDER DIL (2) 

SIGMA 3 GMT/VT DIL (2) 


6. SIGMA 3 (2) 

- STRIP CHARI /ANALOG RECORDERS 

- GMT/VT DISPLAY 

7. SIGMA 5 (1) 

-PRINTER (2) 

- CARD PUNCH (1) 

- card READER (2) 

- MAGNETIC TAPE DRIVES (6) 

- DISKS (3) 



2,4 COST ESTIMATES 


One of the major objectives of this study was to provide rough order "Of-magnitude 
(ROM) cost estimates of the Subsystem and maintenance and operation costs of the 
OCC. Although every effort was made to make these cost estimates as accurate as 
possible, it must be remembered that these are only ROM estimates to be used for 
budgetary and planning purposes. The cost estimates are, of course, directly related 
to the system requirements and resulting design upon wixich they arc based. As the 
mission becomes better miderstood, and the requirements more definitive, it is 
expected that the costs will change from these initial estimates. 


2,4.1 COST ESTIMATING GROUNDRULES AND ASSUMPTIONS 

The following groundrules and assumptions were adopted during this study for purposes 
of arriving at the cost estimates. They are an integral part of the resulting ROM esti- 
mates and should be reviewed closely. 

1. An average labor rate of $48K per year through overhead and G&A 
(and before fee and contingency) was used for each applied man 
throughout the design, fabrication, and test phases of the program. 

This value represents a reasonable mean between the higher paid 
senior engineers/managers and the lesser paid tecrlmicians/sbop 
perscamel. This rate and those used in item 2 below are 1976 rates 
and are used to keep the results of this study compatible with previous 
Landsat-D studies (see Section 1. 1). 

2. Field rates were used for estimating the cost of training operators 
and for the recurring station operations. These rates were supplied 
by NASA/GSFC and are as follows through o\'erhead and G&A per 
year. 

• Manager/Engineers/Supervisors - $36.36K 

• Lead Teclmicians/Operators - $23.64K 
9 Clerical and Support - $13.64K 

3. Overhead, IR&D, and General and Administrative rates arc included as 
appropriate in each of the above man-ye.'’.r labor rate categories (direct 
and field support). The mclusion of these maltes the labor rates used 
fully burdened and thus they only require the final addition of a con- 
tingency factor and profit (or fee). 


2-33 


4. Costs were included for contract support and similar support activity, 
in addition to the basic catalog price for all purchased items. 

5. All costs provided are in basic 1976 dollars; no forwarding pricing or 
inflation factors were used in these estimates. 

6. Where newly designed items are used in more than one subsystem of 
the Landsat-D ground system, the engineering design and drafting 
costs (non-recurring) were only costed once. 

7. Published catalog prices were used for estimating purchased hardware 
and software whenever possible; in a few cases it was necessary to 
rely on engineering estimates and past experience for estimates of 
these purchased items. 

8. The cost estimates presume the use of a private (for profit) contractor 
for all items and include provision for fee or profit at the rate of lO'^f 
on total cost. 

9. No provision in the cost estimates is made for the physical facilities, 
land, security, nor operational utilities (light, power, heat, etc.); 
all of these are assumed to be provided by the government at no 
explicit cost to the project. 

10. A contingency factor of lO*^, is included in the final total cost to 
account for some flexibility in requirements growth and unantici- 
pated cost items. 


2 . 4. 2 COST mEAIOlOW STRUCTURE 

The cost estimates for the Operations Control Center were derived from a 
'bottoms'^p" analysis of each cost element. A cost brealtdown structitre was devel- 
oped to four levels of depth as shown in Figure 2-5. Included on this figure are the 
major task elements which constitute the cost elements. The following descriptions 
summarize the third level of the coat brealcdown structure. 

1, System Engineering - tliis element provides for the overall design 
definition and integration of the various subsystem elements. Design 
reviews are provided for the performance requirements are 
established. 
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TOTAL SUBSYSTEM 
COST FOR 
FIVE YEAR Rll^Olr^ 

10% FEE 

f0% CONTINGENCY 



SYSTEM PERFORMANCE 
INTERFACE DEFINITION 
COMPONENT requirements 
SYSTEM TEST OEFtNiTION 
DESIGN REVIEWS 
TRAINING PLANS 



1 1 — 


1 





integration and 



HARDWARE 



TEST 



- ELECTRICAL DESIGN 



. SUBS'! STEM INTEGRATION 


_ MECHANICAL DESIGN 



. SUBSYSTEM TEST 


_ PACKAGING A CABLING 



. S’* ‘.Ttw level TEf-T 


, DESIGN ANALYSIS 



. SOFTWARE SYSTEM TEST 


. DRAFTING a COhIFIGUflATION 


r TEST PROCEDURES 


■ PURCHASE MATERIAL 



. TEST REPORTS 


. ASSEMBLE COMPONENTS 




. TEST EQUIPMENT 




L INITIAL SPARES INVENTORY 



SITE INSTALLATION 
AND CHECKOUT 



PACKING & 
TRANSPORTATION 
FINAL ACCEPTANCE TEST 
ON-SITE SHAKEOUT 
SITE INSTALLATION 



SOFTWARE DESIGN 
AND TEST 


PROGRAM DESIGN 

flowcharts 

CODE COMPILE DEeUG 
SOFTWARE 1 EVEL TEST 
DOCUM^ NTATiON 
PROGRAM CONTROL 


TRAINING COURSE 
INSTRUCTORS 
OPERATONS TRAINING 
MAlNTEf^ANCE TRAmttlt^ 


PROGRAM management 

CUSTOMER INTERFACE 
•^LHtOULt A CONTROL 
PHOOKt-Ss Ht PORT> 
FINANCIAL REPORTS 
ADMINISTRATION 

integration 

MANAGE ME NT 



OPE RATO k - 
MAINTENANCE 
MANAGEMENT 
SUBCONTRACTS 


CONSUMABLES 
RECURRING SPARES 
EXPE TJOASlES 


Figui'e 2-5., Cost Brealvdown Structure 






2. Equipment Design and Hardware Purchase - tliis element accumulates 
the cost of equipment design and manufacture. Purchase of material 
and bought components; the detailed electrical, mechanical, and pack- 
aging design; the necessary drafting and analysis support; and special 
test equipment design are all included in tliis cost element. 

3. Sofhvare Design and Test - because of the importance of software as a 
key element in digital systems it has been given particular visibility. 
Included are both the software design and software test activities. 

4. System Integration and Test - provides for tlie subsystem and system 
level tests of the integrated components. This is representative of the 
final test at die contractors facility prior to the shipping of equipment 
to tlie installation site. 

5. a.te Installation and Checkout - includes the actual sliipment of equip- 
ment to the opeL'ational site as well as the performance of the final 
acceptance test on the system. 

6. Personnel Training - a training course will be conducted to train the 
on-site field personnel who will operate and maintain the system. 

7. Program Management- provides for die overall management and control 
of die entire systems development activity. Program management, 
administrative, and clerical support are included as well as providing 
for reports and communication with the customer. 

8. Maintenance and Operations - this cost element provides for the yearly 
recurring costs which begin following the final acceptance test. The 
principal cost here is that of the on-site field pec sonnel responsible 
for operating and maintaining tlie system. Costs are also included 
for expendable and consummable material items as well as for 
replacement spare parts. 

2.4. 3 COST ESTIMATING PROCEDURE 

A ’'bottoms-up" cost estimating approach was used to estimate each of the various cost 
elements in the cost breakdown structure. In all cases die initial engineering and manu- 
facturing cost estimates were reviewed hy three levels of management to ensure their 
accuracy and consistency with recent experience. The follo\ving paragraphs are intended 
to provide some understaiiding of the rules-of-thumb applied and the procedures followed. 
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For each of the subsystems, a parts list was developed with each part identified and 
costed. A percentage was added to the catalog price of purchased items for the contract 
support required to generate the documentation and provide tlie necessary controls to 
purchase all buy items. The cost of the materials required for tlie newly designed items 
was estimated based on experience with similar items developed for previous ground 
stations. The labor effort required to design and manufacture the make items, and to 
provide the necessary design and manufacturing effort to develop the source control draw- 
ings, prociu'ement specifications, and to assemble the buy items, were also estimutc’d 
based on cxperis nee gained nith similar equipment. 

Catalog prices were used for all purchased items. Tlie lalior effort required for the 
design, drafting, and manufacturing of new items was based on experience with similar 
equipment, with appropriate complexily factors to adjust the total cost. Material costs 
were based on the number of electrcnic circuit boards, the number of parts per board, 
etc. The systems engineering task was costed based on a level of effort across the 21 
month assumed program duration. No discounts were included in any of tlie liardware 
or software costing. 

Ten (10} percent of the total material dollars were added to accoimt for non-recurring 
spares. No specific analysis was conducted as to the detailed repair and replacement 
level nor were particular equipments identified for sparing. Rather, the 10% rule of 
thumb was applied across the board. 

Catalog prices were used for all purchased software pacl<ages. The labor required to 
design the operational and test software, and to perform the debug and verification, was 
based on experience with similar software systems developed on previous programs and 
adjusted according to their relative complexities. 

The System Integration and Test task was costed by estimating the number of people 
required to conduct and operate tlie particular subsystem equipment over the integration 
and test period. 
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The cost to pack and sMp each subsystem was based on tlie number of equivalent single 
bay racks weighing approximately 800 pounds each. Each rack would be supported on a 
skid (100 pounds each) and the cost for shipping is approximately $20 per 100 pounds. 

The installation and acceptance test efforts were costed based on the estimated number 
of men required over the given installation and test periods. 

Traiiiing was costed by estimating the number of operators to be trained along with their 
associated labor category. Field rates were used for all site personnel and the stanclaixl 
conti actor rates were used for the Instructors. The training time allocated is basutl on 
the relative complexity of the subsystem. 

Maintenance and operations were costed by estimating the number of man years/labor 
category required to perform OCC tasks. Tlie NASA supplied field rates were used. An 
expenditure of 1 % of the total material dollars was added for non-replaceable spare parts, 

2,4.4 COST ESTIMATES 

Five-year runout OCC cost estimates are summarized in Table 2-4 and Table 2-5, for 
recurring and non-recurring costs respectively. 



Table 2-4. Non-Recurring Costs 

task: 

System Engineering 240 

Equipment 3116 

Software 1420 

System Iht ^ration 120 

Site Installation 50 

Training 144 

Program Management 214 

Total 5304 

Thru Fee 6418 

1976 DoUars x 1000 

Thru Fee = use of 10% fee and 10% contingency 
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Table 2-5. Recurring Costs 


CATEGORY 

Manpower 90S 

Materials 63 

Total 971 

HiruEee 1175 


1976 Dollars per year x 1000 

Thru Eee =use of 10% fee and 10% caatingeuoy 
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SECTION 3 

OCC COMPATmiLITY WITH POCCNET 

As was discussed in the Preface, this OCC Final Report has been divided into two rela- 
tively "stand-alone" sections. The previous Section 2, discussed the original study 
etfort aimed at producing a baseline OCC design and cost estimate. The study contract 
was modified to include an investigation of the POCCNET concept as applied to Landsat-D; 
these results are reported here in Section 3. 

Because of "stand-alone" nature of Sections 2 and 3 there is some redundancy of material 
between the two sections. These sections which are redundant have been marked with 
an asterisk (*) following the title. 

3.1 OCC REQUI P "~^ fENTS * 

The OCC has thre. major areas of reS; -"^sibility in the performance of its functions. 

These are: 

1. Data Management 

2. Flight Operations Command 

3. Spacecraft and payload performance evaluation 

Figure 3-1 illustrates the Landsat-D functional interfaces required to perform these functions. 


3.1.1 DATA MANAGEMENT GROUP (DMGl* 

Planning and scheduling functions which define the spacecraft and ground activities 
necessary to effectively satisfy the mission and flight operation requirements are performed 
by the Data Management Group (DMG). The plans and schedules must be based upon sensor 
coverage requirements, spacecraft and payload configuration, network availability, and 
environmental constraints. The resultant activify plan is a time-ordered list of spacecraft, 
payload, and network events. 
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Figure 3-1 . Lands at-D Functional Interfaces * 
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The planoiag and scheduling responsibilities of DMG cover all elements of the operational 
mission system and must be designed to make the most effective use of the resources of that 
system. 

3.1. 1.1 Sensor Coverage Requirements * 

The Data Management Group has the responsibility of receiving requests for Payload Data 
from the NASA Data Utilization Office, the Landsat Project Office, and some special 
users and integrating them into the scheduling data base. This data base is used to 
schedule the on-board payload as well as provide management reports containing, but not 
restricted to the following information. 

a. All outstanding requests for Landsat images. 

b. All satisfied requests for Landsat images and the assessment of each image. 

c. All in-process requests and their state of completion. 

The maintenance of this data base requires feedbaclt from the CDPF on the status of all 
in-process payload data. 

3. 1.1.2 Spacecraft and Payload Configuration * 

Spacecraft and payload configuration must be considered in the development of the activity 
plan in order to ensure that the current resources of the spacecraft are effectively 
utilized. Changes in the status or operability of the spacecraft or payload must be identi- 
fied and input to the activity planning function in order to prevent any compromise to 
spacecraft health and safety. 

3.1. 1.3 Network Availability * 

Network availability must be determined for emergency contact operations as well as 
tracldng. Tracldng requirements will be input to DMG by the NASA Orbit Determination 
Group and will define requirements for both routine tracking and special tracking for 
orbit adjust maneuvers. Orbit adjust requirements will be determined by the Flight 
Dynamics Group (FDG) and input to the DMG. The DMG must factor these requirements into 
the activity plan. The DMG must coordinate all network support requirements with STDN 
and be capable of iterating the activity plan as a result of network schedule conflicts. 
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In addition, the DMG must maintain a constant availability status with the Tracking and 
Data Relay Satellite System (TDRSS). All data collection (other than Direct Readout) 
and tracldng will normally be performed through the TDRSS System. 

3. 1.1.4 Environmental Constraints * 

Environmental constraints include those factors wMch affect or restrict payload operations 
such as sun angle and weather. 

3. 1.1. 5 Spacecraft Location and Attitude Data Processing * 

The CDPF requires spacecraft location and attitude data to correctly process the payload 
sensor data. The spacecraft attitude data is extracted from the spacecraft telemetry 
data by the OCC and is condensed with location data supplied by the Orbit Determination 
Group. This data is then transferred to the CDPF for use in payload data processing. 

3.1.2 FLIGHT OPERATIONS CONTROL* 

The OCC is the focal point for Landsat-D in-orbit operations. The OCC operations control 
function must, therefore, be capdDle of integrating and directing both the internal OCC 
activities and the external network support activities to ensure execution of the activity 
plan provided by the OCC scheduling function. The operations control function must also 
be capable of rapid and effective response to contingencies in both the spacecraft and 
ground support systems. 

The internal OCC activities associated with the OCC operations control functions include 
spacecraft command generation, transmission, and verification; real-time spacecraft 
and payload performance evaluation; payload data reception and recording; and coordination 
of the associated OCC computing support. 

These internal activities must also be coordinated with the scheduled network support 
activities in order to maximize the effectiveness of the OCC operations. 

3. 1.2.1 Spacecraft Command Generation, Transmission and Verification * 

The OCC is required to generate the commands necessary to operate the spacecraft and 
its payload. Command generation responsibility include: 
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1. Compilation of commands which satisfy the activity plan and spacecraft 
system performance and configuration requirements. 

2. Display and verification of commands prior to transmission to ensure that 
the command list is correct and does not violate prescribed operational 
procedures. 

3. Blocldng and formatting of commands and transmission via the appropriate 
support network. 

4. Verification of command ejsecution in the spacecraft for both real-time and 
stored program commands. 

3. 1.2. 2 Real-Time Monitoring of Spacecraft and Payload Performance * 

The OCC is responsible for the analysis and evaluation of spacecraft and payload data to 
determine their configuration, health, and performance at both a system and subsystem 
level. Real-time processing and analysis are required to permit on-line command and 
contx'ol over the spacecraft. Implicit witlnn tliis requirement is the fact tliat the OCC 
must be capable of receiving, processing, displaying, distributing, and storing the 
spacecraft data necessary to fulfill these responsibilities. 

3. 1.2. 3 Payload Data Reception ^ 

The CDPF/DIS is the focal point for the reception of the payload data. The data will be 
transmitted from the TDKSS ground station to GSFC via the DOMSAT relay. The OCC 
will receive incoming payload data for a "quick look" display. 

3. 1. 3 SPACECRAFT AND PAYT.OAD PERFORMANCE EVALUATION* 

The OCC is responsible not only for the short-term spacecraft configuration and health, 
but also for long-term trend analysis, investigation of anomalies, and for the liistorical 
repcrting of spacecraft and payload performance. The performance evaluation fimction 
uses all available sources (telemetry and video data, strip chart records, system scheduler 
outputs, etc.) to analyze the spacecraft and payload performance on an in-depth, long- 
term basis and to investigate anomalies in the spacecraft and payload systems. 

Periodic reports are generated to disseminate information on the spacecraft and payload 
performance. 
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3.2 DESIGN OVERVIEW 

This seciion describes an OCC configuration approach that will allow the Control Center 
to function totally as an independent component or as part of POCCNET. With the 
configuration as shown in Figure 3-2, the OCC Functional Requirements are satisfied 
by the following seven major subsystems: 

1. PCM Data Processing 

2. Video Display and Evduation 

3. Command Generation 

4. Communications and Data Distribution 

5. Status Data Control and Display 
G, System Scheduler 

7. Computing Services 



Figure 3-2. Landaat-D OCC Configuration 
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POCCNET is a set of services that will be used by the Lands at- DOCC. The POCCNET 
is a network of Operations Control Centers at Goddard. The POCCNET concept views 
all POCC's as a set of Telemetry and Command (TAG) systems. Applications Processors 
(AP), displays and other peripherals and external interfaces. The POCCNET will provide 
the protocols so that all these data processing elements can talk to each other through 
an Inter-Process Communications (IPC) net. The resource allocation will be, at the 
request of the POCC's, under control of Data Operations Control Center (DOCC). 

The POCCNET concept also includes a Data Base Storage (DBS) service, Gateways and 
Virtual Interface Processors (VIP). The DBS allows POCC users to use the POCCNET 
data storage as a mailbox or a scratch area. Gateways are matched interfaces to 
external communications nets that do not use POCCNET protocols (e. g. , to Johnson Space 
Center). The VIP is a computer that drives the OCC peripherals. It allows the user 
computer systems (DOCC's, AP's, TAC's) to see a standard interface for its replaceable 
peripherals. Thus, only the VIP would know the specific device characteristics and 
idiosyncracies. 

The POCCNET is described in detail in "A Conoept for a Payload Operations Control 
Center Network (POCCNET)" by R. des Jardins and J. Hahn, November 1976, Goddard 
Space Flight Center. (Document #X-510-76-250) 

The Landsat-D OCC will be designed to work using the POCCNET concepts but not depen- 
dent on the POCCNET itself. Thus, there will be TAC's, VIP's and AP's but, in addition 
to the POCCNET IPC, DOCC and DBS, there will be a more limited Landsat-D ocC IPC, 
DOCC and disk storage system. 

3.2.1 OCC CONFIGURATION IMPLEMENTATION 

The Control Center consists of two Applications Processors, two VIP computers, two TAG 
Computers, and a Private Storage Disk Pool that can be made available to either appli- 
cation processor. 

Following is a brief description of die functions performed by each of these computers. 
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The on-line Applications Processor (AP) performs on-line PCM, Data Processing OLS, 
and Command Transmission Functions. 

The off-line Applications Processor (AP^) performs Mission Planning, management 
Report Generation, Slat Generation, and is a hot backup for the on-line AP. 

The on-line Tdemetry and Command Computer (TAG) performs the command and 
telemetry formatting fimction. 

The off-line Telemetry and Command Computer (TAC^) is available for backup, Software 
Development or Second Spacecraft Support. 

Tile on-line Virtual Interface Processor (VIP) functions as the Peripheral Interface for 
all OCC display devices. 

The off-line Virtual Interface Processor (VIP^) is available for backup to VIP, Software 
Development or a Second Spacecraft Operation, 

The Bulk Storage Disc Pool is switchable between either application processor. The pool 
will normally be selected by the Application Processor that is performing Administrative 
Functions, Slat, Management Reports, etc. 

3.2.2 PCM DATA PROCESSING SUBSYSTEM 

The PCM Data Processing Subsystem, performs the functions required by the OCC for 
the processing, analysis, and evaluation of the spacecraft telemetry data. This sub- 
system consists primarily of telemetry processing applications software operating within 
tile OCC Applications computer. The PCM Data Processing Subsystem operates on real- 
time telemetx'y data and consists of tliree software elements (Figure 3-3). 

1. Input Software. Decommutates all spacecraft telemetry data input to the OCC 
and prepares it for further computer processing. 

2. On-Line Processing and Analysis Software . Pimcesaes all decommutated 
spacecraft telemetry for real-time display and evaluation and prepares the 
data for off-line processing. 

3. Off-Line Processing and Analysis Software. Processes spacecraft telemetry 
data for in-depth evaluation of system and subsystem performance. 
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Mgure 3-3. PCM Processing Subsystem Elements 


3.2. 2.1 Input Software 

The Input Software operates in the OCC Td.emetry and Command processor, which is 
part of the OCC Computing Services Subsystem described in Section 3.2*8. All spacecraft 
telemetry data received at the OCC is input to the TAG processor and is operated on by 
the Input Software. 

The real-time data is input to the Input Software in block format. The TAG system per- 
forms the processing necessary to establish frame, subframe, and word sync, and then 
transfers the data, one major frame at a time, to the On-Line Processor and Analysis 
Software operating in the OCC Applications computer. 

The software first verifies the NASCOM header data to insure that this block contains 
telemetry data intended for the OCC. 


Command status blocks, which also arrive at the TAG processor, are processed as 
described in Section 3. 2. 4. Other bloclcs (e. g. Time code) are stripped and passed un- 
modified in a standard message, to the OCC Applications computer. 
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3.2.2. 2 On-Line Processing and Analysis Software 

The On-Line Processing and Analysis Software (ONPAS) runs in the OCC Applications 
computer and operates in conjunction with the Input Software. ONPAS accepts and 
processes real-time data, alerts the Display Report Generators (Section 3.2. 6. 3) and 
performs the frame-by-frame processing functions. The On-Line software also gener- 
ates a raw data tape containing real-time telemetry data, and writes the new telemetry 
data into theLandsat-D data base both locally and in the POCCNET DBS. 

The ONPAS system consists of a number of Telemetry Processing Packages, designed i 
to perform the following seven functions: 

1. Reformatting. Basically a data unpacking and reordering function. 

2. Range Check. Fitting analog values into various size "bins". 

3. Status Determination. Verification of the necessary indicators of spacecraft 
status. 

4. Calibration . Each telemetry sample is converted to engineering units by means 
of stored look-up tables. 

5. Pseudo-Function Generator. Additional spacecraft performance measures, 
such as operating efficiencies, power outputs, etc. , which are computed from 
the telemetry data are generated. 

6. Smoothing . Transient noise is removed from the telemetry data prior to 
further processing. 

7. Data Base Update. Write the new raw telemetry into the Landsat data base, 
frame by frame. 

If the primary AP goes down, the alternate AP will take over. The current status will 
be derived from the telemetry written into the POCCNET DBS (or, if there is no 
POCCNET from a data base storage area accessible by both Landsat-D OCC AP's). A 
requirement on the alternate AP is that it must have a resident copy of the On-Line 
processing software. 





3.2.2. 3 Qf£>-Lme Processing and Analysis Software 

The Off-Line Processing and Analysis Software (OFPAS) accepts telemetry data, via the 
EDT or the On-Line data base and performs the in-depth processing required for detailed 
evaluation of system and subsystem performance. (See Figure 3-4). 



Figure 3-4. Off-Line Processing and Analysis Software 

OFPAS consists of individual processing packages operating under the control of the Off- 
Line Supervisor (OLS). OLS establishes the processing order, controls the linkages, 
and brings in the data from data base. Ofif-Lim packages each process all of the data on 
a ficame-by-frame basis and collect the necessary information from each frame as re- 
quired. When the last frame has been processed, the statistical and other calculations 
are made and tlie results compiled for display by the display software. With the excep- 
tion of a Generalized Statistics Routine (GSR), the processing packages may be run in 
any order. The GSR computes the minimum, maximum, mean and standard deviation 
unconditionally for a function over the entire orbit span and/or may be computed on an 
operating mode basis. GSR computes statistics for subsequent display, trend plotting, 
historical archiving, and for use by the other OFPAS processing packages. 

The remaining processing packages operate on and compute data for the analysis of 
specific spacecraft functions or subsystems, as their titles imply. At the conclusion 
of this processing the OLS compiles the results of these individual processing functions 
and wraps up the off-line processing by compiling the data to be plotted on the OCC 
plotter. The plot data is generated by the GSR and the other processing packages of 
OFPAS, The plot data compiled by OLS is transferred to the display software where 
it wiU be displayed on a graphics terminal. 
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3.2.3 VIDEO DISPLAY AND EVALUATION SDBSYSTEM=»^ 

Tile Image Data Processing and Display Subsystem in the OCC provides the ability to 
monitor sensor operations during real-time NTTF station contact. This capabilily ‘Will 
allow real-time evaluation of payload operation and response to command. 

3. 2. 3.1 Sensor Payload Performance Evaluation* 

Evaluation of the performance of the spaceborne payloads will be baaed on the utilization 
of three data sources: 

1. Quick look video displays from the OCC Image Data Processing and Display 
Subsystem. 

2. Payload Telemetry Points processed by the OCC PCM Processing Subsystem. 

3. High quality imagery generated by the CDPF Image Processing Subsystem. 

The following paragraphs describe how each of the data sources will be utilized to provide 
maximum confidence in payload status, health aud performance. 

3 . 2 . 3 . 1. 1 Evaluation Using Quick-Look Display* 

One of the most effective supervisory tools for assessing sensor performance is the 
formed image firom the sensor itself. Unfortunately, the types of sensors used feature 
a low line rate video and do not lend themselves to a real-time display. Expedients, such 
as open lens camera attachments must be used to circumvent the inability of human eye 
to integrate the slow scan, signal and permit evaluation of the quality of the image and, 
therefore, sensor performance. 

A camera, most conveniently a Polaroid system camera, coupled to a CRT display, 
can provide the integration of the data into picture information for evaluation fay the human 
eye. Unfortunately, the time elapsed fL*om the initial signal arrival to that of a completed 
picture is significant, but it is nearest to real-time evaluation of a Ml coherent frame. 


Because a picture frame is composed of individual ’’lines" of electrical signals assembled 
on a basis of synchronizing signals, a correctly appearing picture will assure the super- 
visory personnel of proper operation of the camera. Any other displeasing effect .n the 
obtained pictures is indicative of difficulties. A number of operational problems can be 
detected to some extent: 

1. Geometric distortion (large percentages only). 

2. Sync failures. 

3. Line dropouts. 

4. Interference of various kinds. 

5. Calibration signal status. 

6. Gray scale calibration {if provided in the sensor) 

Other problems more or less obvious, but quite evident, to an experienced sensor per- 
formance evaluator can also be detected. 

The second supervisory tool is certainly an on-line oscilloscope display, set up to show 
on its CRT screen the individual incoming signals. Based on familiarity with "good" 
signals, the nomalous signals can be easily spotted. Nevertheless, once the oscilloscope 
display shows defective signals, the hard copy picture will also be improper. 

3 . 2 . 3 . 1 . 2 Evaluation Using PCM Teleme try Data* 

The second source of performance evaluation data is the processed sensor telemetry. 
Telemetry evaluation, in general, is simple once the past history of given equipment is 
shown and familiarity with it exists. 

During the integration tests, strip charts of sensor telemetry are made on a routine basis. 
Telemetry and calibration compendiums are compiled and contain waveforms that appear 
under all possible modes of operation. Similarly, from the real time orbital operations, 
the strip chart recording is performed for both real-time and off-line detection and 
analysis of abnormal conditions. 

More comprehensive data describing the overall operation of the payloads is generated 
by the PCM processing software described in Section 3.2.2. TMs software processes the 
payload houseiieeping data from telemetry data to produce a report of sensor performance 
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whicli defines the opea?ational profile of all sensor activities. In addition, the data is 
used to compute statistical and trend data required for tong term performance evaluation. 

3.2. 3. 1.3 Evaluation Using CDPF Imagery* ' 

The evaluation described previously was concerned primarily with the identification of 
anomalies in sensor performance which could endanger the spacecraft or impair the 
performance characteristics of the payload. These factors cannot generally be det ected 
at the quick look level of image evaluation, but must be done from an examination of high 
quality images. 

The guidelines for evaluation wiH be firmly established once real imagery feom the 
respective sensors has become available and test and integration experience has been 
gained. 


3.2.4 COMMAND GENERATION SUBSYSTEM* 

The Command Generation Subsystem is designed to compile, format, transmit and verify 
spacecraft commands at the OCC. Commands are compiled in advance from the activity 
plan generated by the System Scheduling software (reference Section 3.2.7). During the 
real-time acquisition the command messages are formatted, verified, and transmi+ted 
automatically, but under command operator control. All commands generated by. the 
OCC are routed to the remote sites for RE transmission to the spacecraft. 


The Command Generation Subsystem consists of three software packages: the Command 
Compilation Software (CCS) and Command Management Software (CMS) which operate in 
the OCC Applications Processor and the Command Blocldng software in the TAG computer. 
The CCS operates off-line and is used by the command operator to compile the command 
list from the aotivify plan, and store it in the Landsat data base. The CMS provides the 
command operator with the full capability to add to, delete from, or change the compiled 
command list and to transmit both real-time and stored commands to the spacecraft 
troni the command panel at his operations console. The Command Blocker blocks and 
formats the commands and is responsible for getting them to the uplink command site. 
Figure 3-5 depicts the Com m and Generation Subsystem flow. 
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Figure 3-5 . Command Generation Subsystem Flow 
3,2.4. 1 Command Compilation Software (CCS)* 

The function of the CCS is to translate desired spacecraft events, defined in the activities 
plan (generated by System Scheduling Software) into the appropriate spacecraft command 
sequences which will cause those events to occur. The CCS functions in the non real- 
time environment and provides no functions required during the on-line command 
transmission. 

The input to the Command Compiler is the Activity Plan generated by the System Scheduling 
Software, This Activity Plan resides m the OCC computer and will be assessed at 
program execution time. For each event listed in the Activity Plan, the CCS will generate 
the required command or sequence of commands to perform that event. The output of 
the Command Compiler will be a report which describes the spacecraft commands and 
their execution times. Commands which are to be executed within a predicted RT acqui- 
sition window will be formatted for transmission as real-time commands (RTC's), 
Coi-imands which are to be executed outside a RT acquisition window will be formatted 
for transmission as stored commands. Critical commands included in the list will be 
flagged for the operator. 
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3. 2. 4. 2 Command Manageinent Software (CMS)* 

The CMS performs the processing required to transmit commands to the spacecraft under 
control of the command operator. This software is normally co-resident with the ONPAS 
of the PCM^rocessing subsystem (Section 3.2.2) and the Status Data Control and Display 
Subsystem software (section 3.2.6) and operates in conjunction with this software. The 
CMS has the highest computer system priority in terms of central processor time, 
resource allocation and report display processing. 

CMS operations are initiated for the most part fcy the command operator inputs from his 
operations console. The commands are sent by the DMS to the TAC computer. The CMS 
later extracts telemetry elements to decide upon the success of the command and displays 
these special points on a command display. 

The preliminary command list resulting from the CMS is displayed for the command 
operator on request. The operator has the capability to edit, delete and insert both 
single commands and command sequences from the command console. 

At the conclusion of this process the complete command list is displayed for review and 
approval. The command list, with its sequence annotation, is stored within tlie OCC 
computer for subsequent call-up by the CMS during the real-time acquisition period. 

3. 2. 4. 3 Command Block Software 

The Command Blocldng Software in the TAC processor is responsible for the blocking, 
reformatting and transmission of command messages from the Dandsat Applications 
Processor. 

The Command Block function will gather the messages into a NASCOM block, insert 
network protocol overhead, do the polynomial encoding and send the command message 
block to the uplink site. It will handle all command status blocks from the site that deal 
wltli command message protocol. Command status messages that are related to message 
content or command transmission problems are stripped and sent to the Applications 
Processor. 
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3. 2. 4.4 Command System Baclmp - 


The Command System components - the AP, VIP, displays and TAG - each have an 
available backup in the alternate side ol the Landsat-D OCC. If the primary on-line 
component goes down, the backup can be switched in through the POCCNET IPC or the 
Landsat-D IPC. (The alternate system will have co-resident inactive copies of the 
command and telemetry processing software. ) 

3.2.5 COMMUmCATIONS AND DATA DISTRIBUTION SUBSYSTEM (C&DD)* 

The C&DD Subsystem configuration is shown in Figure 3-6. The C&DD Subsystem 
consists of the input/ouiput signal conditioning and switching equipment, the OCC/CDPT 

computer switching equipment, the timing equipment, the maintenance and operational 
consoles for the OCC, the voice communications equii^ment, the magnetic tape recorders, 
and the simulation equipment. Tlie voice communications equipment is expected to be 
government furnished equipment, with the remaining portions of the subsystem furnished 
by the contractor. The C&DD Subsystem acquires data inputs, provides signal con- 
ditioning where necessary, and provides for the switching/patching and recording of PCM 
signal inputs, command outputs, timing signals, simulated PCM signals, and Computer 
Subsystem input/output channe!.s to the OCC Computer Subsystem and the Control and 
Display Subsystem. Coordination of OCC operations with the Landsat-D system is pro- 
vided by use of voice communication equipment. 

The- C&DD Subsystem consists of several functional groups of equipment. These groups 
are: 

1. Signal Conditioning and Switching (SCS) 

2. Timing 

3. Computer Subsystem Switching (CSS) 

4. Maintenance and Operational (M&O) 

5. Voice Communications 
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ligure 3-6. OCC Comimini cations and Data Handling Distri'bution Subsystem 













3.2. 5.1 Signal Conditioning and Switching * 

The Signal Conditloiiing and Switching (SCS) equipment acquires data, provides signal 
conditioning where necessary, and provides for the switching and/or patching of PCM 
signal inputs, tisning signals, simulated PCM signals, and command outputs to the 
magnetic recording equipment, the M&O console, the timing equipment, the Computer 
Subsystem and the Control and Display Subsystem, as required. The SCS will he 
remotely controlled from the M&O console described below. 

3. 2. 5. 2 Timing * 

The timing equipment receives timing reference signals from the GSFC timing facility 
and from the Computer Subsystem- In addition, the timing equipment receives pass lime 
SET/START/STOP/HOLD commands from the Control and Display Subsystem. The 
formatted timing equipment outputs will be sent to the magnetic tape recording equipment, 
the Computer Subsystem, and to the Control and Display Subsystem for time correlation 
purposes. 

3. 2. 5.3 Computer Subsystem Switching 

The Computer Subsystem Switching (CSS) Equipment is capable of switcliing the necessary 
input/output signals for any combination of the TAC, VIP, and AP computers into the 
on-line configuration. Those computers which are not on-line will be available for off- 
line use by the DMG for Data Management functions, or alternatively may be placed on 
a network available status for use by other POCCNET control centers. Control of the 
CSS will be remoted to the MStO console. The computer configuration, including the 
status of those components controlled by software switching, will be available at all 
times to the OCC personnel via status panels at the operations and M&O consoles. 

3. 2. 5. 4 Magnetic Tape Recording * 

The magnetic tape recording (MTR) equipment provides for the recording and reproducing 
of the PCM command and simtilated PCM data from the signal conditioning and switching 

equipment, and the time code from the timing equipment. The MTR equipment will 
contain two reoording/reproducing units. One unit will be used for normal operation, 
with the otlier unit available for bacluip capability. Monitoring and control of the recorder 
operation "'.vill be remoted to the M&O console. 
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3.2. 5.5 Maintenance and OperatioDs Coiasole * 

The maintenance and operation *M&0) console will be used to control the OCC system 
configuratiGn, to select the OCC data input, and to monitor the OCC system performance/ 
status. The M&O console operator will provide the interface between the operations 
supervisor and the NASA data handling and scheduling organizations. 

3.2. 5. 6 Voice Communications * 

The OCC voice circuits, associated hardware, and interfaces will be Government 
furnished Equipment. Several operational positions will need Private Branch Exchanges 
(PB;^, Switciiing Conference and Monitoring Arrangement (SCAMA), interfaces to 
remote ground network, and Closed Circuit Loop (CCL) channels for GSFC internal 
communications , 

Installation of key sets and communications panels will be accomplished under the 
auspices of the NASA Communications (NASCOM) organization at GSFC, Standard 
communications panels will be furnished to the designated operational and maintenance 
positions. For the most part, operational positions will use the standard communications 
panels, accommodating 30 or 60 pushbuttons. 

3 . 2 . G STATQS DATA C ONTROL AND DISPLAY* 

The Status Data Control and Display Subsystem consists of the hardware and software 
necessary to present, maintain, and update the mission system and spacecraft system 
status data essential to flight operations. A block diagram of the subsystem is presented 
in Figure 3-7. Tlie major components of this subsystem are: 

1. OCC operations ccinsoles. 

2. Strip chaif and event display recorders, 

3. Display control and report generation software which operates in. the 
OCC computer. 
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Figure 3-7. Control and Display Subsystem Block Diagram* 













3*2, 6.1 Operations Consoles * 

Four consoles are required witliin. tlie OCC Operations Control Room. The four consoles 
have been identified as; 

1. Operations Supervisor (OS) consoles 

2. Command Console 

3. Spacecraft Evaluator Console (2) 

The OS console, Command console, and Spacecraft Evaluator Consoles will all have the 
same basic configuration. The addition of special panels and associated cabling to the 
basic configuration will produce the OS and Command consoles. Each console is equipped 
with a CRT display and a standard input keyboard and programmable function keys which 
permit access to the OCC computer. In addition, the consoles are equipped with a spacecraft 

time clock, GMT clock, pass time clock, communications panel, and a small matrix 
of status and alarm indicators driven by the computer which can be programmed 
according to each console’s function. Both the Command and OS consoles also contain 
a Command panel for the initiation of commands. This panel is provided at both con- 
soles for baclcup. The computer will only permit command inputs from one panel at 
any time. 


3.2. 6.2 Strip Chart and Event Recorders * 

The strip chart and event recorders provide the capability for displaying dynamic analog 
data in a more meaningful manner than the CRT’s permit. This is especially true in die 
case of certain attitude control and other subsystem parameters. In addition, these 
recorders present the data in recognizable and repeatable patterns which can be readily 
interpreted as performance signatures from which anomalies are readily detectable. In 
other cases, these recorders serve as short term trend plots which, again, permit 
rapid identification of anomalies. 
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Under normal conditions the portable strip chart recorders and the event 
recorder will be located in the Operations Control room. Each of the strip chart recorders 
has the capability of displaying eight analog and eight discrete signals. Tlie portable 
recorders are used in conjunction with spacecraft and payload evaluation functions con- 
ducted at the operations consoles. Tliis arrangement affords full benefit from the multi- 
processing mode of the OCC computer system and the interactive capability of the con- 
soles. The system can operate on several processing requests simultaneously and can 
present the results of this processing to any of the appropriate devices. 

The strip chart and event recorders also serve as a critical backup display capability 
within die OCC. In tlie computer system configuration described in Section 3.2. 7, 
these recorder are driven by the system’s communication processor. This processor 
is capable of operating in a stand-alone mode without benefit of the OCC central processor. 
In the event of CPU failure during real-time spacecraft operations, the communications 
processor would continue to present selected PCM data to these recorders, thus providing 
a signifi cant backup PCM display capability for spacecraft evaluation. 


3*2. 6,3 Display Control and Eeport Generation Software 

Display generation and control within the Control and Display subsystem is performed 
primarily by two software packages, the Report Generator Supervisor (RGS) and the 
Report Generator Packages (RGP). 

The purpose of the Report Generator Subsystem (RGS) is to supervise the presentation 
of requested displays at the operations consoles by supervising the loading of tlie required 
Report Generator Packages. 


The Report Generators will be loaded at the request of the RGS into partitions known by 
the Applications Processor operating system. Tlie RGS receives the display requests 
(through a VIP and the CS) when the operator keys-in the request. 
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The Report Generators interface with the operating system to request data updates when 
the new t^emetry arrives. Thus, for each new telemetry frame, the operating system 
will signal each of the requesting Report Generators which will then drive the appropriate 
virtual devices with updates. 

The Report Generator Packages will also contain all of the formatting statements, and 
tabular and columnar information required to display the report information in a meaning- 
ful presentation at any of the operations consoles or printer. They wiU read this infor- 
mation from files in the Landsat data base. 

Analog and digital PCM data, displayed on strip chart and event recorders located at the 
operations consoles, will be processed in the same manner by special Report Generators 
that make use of the virtual device interface that allows strip chart recorders to appear 
as virtual displays. 

Data required for trend analysis will be ecstracted post-pass from the telemetry file for 
this orbit. This data wtil be extracted, converted, and formatted in the codes appro- 
priate for input to a graphics display. The software required to do the extraction, 
formatting, and conversion is the Plot Data Formatter (PDF). This program will run 
under control of the Off-Line Supervisor in the post-pass environment. 


3.2.7 SYSTEM SCHEDULING SUBSYSTEM* 

The System Scheduling Subsystem defines the sdieduling of sensor operations that v u 
effectively use the data collection capability of the spaceborne observation system, and 
the scheduling of necessary grpund system support operations such as tracking, orbit 
maintenance and ground station contacts. 

System Scheduling generates an overall system activity plan based on coverage require- 
ments, spacecraft and payload status, network availability, and environmental constraints. 
The activity plan produced must be a time-ordered list of spacecraft, payload and network 
events that do not violate any operational constraint imposed on the Landsat system. 

The subsystem is primarily a non real-time, data-base oriented, software system. 
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The Sijrstem Scheduling Subsystem provides the mission planner with a computational 
and boold^eeping aid to assist him in the selection of a specific mission profile which 
efficiently uses the data collection capability’ of the Landsat system. 

The requirement to incorporate timely weather predictions compounds the problem of 
selecting an effective system schedule by minimizing the time available between 
receipt of weather predictions and generation of commands. Thus, the problem is to 
determine an efficient system schedule without violating any operational, expendable, 
or environmental constraint within a limited computation time. 

The subsyst.em represents a computer aided approach to the system scheduling problem 
that facilitates the generation of overall system schedules within all of the aforementioned 
constraints. The key feature of the system is that it is computed-aided; e.g. , tlie OCC 
computer is utilized to perform routine arithmetic data processing, and to report constraint 
conflicts indentified by the computer. In all cases, manual intervention can override 
computfer generated decisions. 



3.2. 7.1 Sysfcein Overview 


System Scheduling will generate the spacecraft activity plans that will be the input to the 
Command Compiler Software Package. System Scheduling will determine Station Support 
Requirements and initiate the scheduling there of Jt will generate video tape directories 
and determine requirement for Ephemeris. The System Scheduling shall, in meeting 
its basic responsibilities, be required to direciiy interface with the following groups; 

1. NASA Project Office 

2. Network Scheduling (MISSOC/OPSCON) 

3. Orbit Detm:'mination Group (ODG) 

4. Central Data Processing Facility (CDPF) 

5. National Oceangraphxe Atmospheric Administration (NOAA) 

6. User Community 

7. The design of files and data tables coupled with a sequence of parameter 
computations that minimizes the data handling problem and the necessity 
for recalculation of parameters. 

8. The inclusion of the mission planner in the system to perform certain critical 
decision-making functions; e.g, , resolution of computer identified constraint 
conflicts. 


The System Scheduling subsystem may be considered to consist of three major sections: 

1. The system scheduling supervisor which provides overall system control, 
initialization, and r^ort generation. 

2. A data preprocessing section in which geometric coverage computations and 
filtering on coverage area characteristics and sun angle are performed. 

3. The activity scheduling section in which coverage area availability is filtered 
by predicted weather, and then spacecraft, payload and network schedules 
are generated and integrated into a comprehensive activity plan. 
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3,2. 7.2 Spacecraft Activity Plan Generaiioii 

3. 2. 7. 2. 1 Edit Program 

The Edit Program allows additions, deletions, and changes to 360 DATA BASE by creation 
of a new tape YPRM or Y1050, 

3. 2. 7. 2. 2 Conversion to Frame World Program 

The Conversion to Frame World program converts the latitude and longitude coordinates 
from the YPRM or YL050 tape to frame world coordinates and creates the tape merge. 

3.2. 7.2. 3 Frame to Priority Merge Program 

The Frame to Priority Merge Program reads the merge tape and using the merge 
operator adds the effort index from the Priority Card input to generate tape MAPU. 

3 .2 . 7. 2. 4 Area Definition 

The Area Definition program takes the requested frame data from MAPU and compares 
it with the frame taken history data base for the orbits under consideration to find which 
frames are still desired. It then adds the additional areas from the KITTI file and gen- 
erates the area definition file (ADTDB), 

3. 2. 7. 2. 5 Area Availability 

The Area Availability program uses sun angle and spacecraft locations from ODG supplied 
ephemeris data in conjunction with predicted cloud to modify the desired areas from the 
(ADTDB) and assign start and stop center frame times references to the Equator to each 
available area after the sun angle and cloud cover predictions have modified the area. 

This is done via the AADP operator which generates the area availability table (AATBL) 
and the descending node table (DESNTBL), 

INPUTS: 

1, The Area Definition Table (ADTDB) contains all the desired areas for 
the night's scheduling. 

2, The Predicted Fit Ephemeris contains the subsatellite trace and sun 
angles versus time in one-minute increments. 

3, The card inputs to Area Availability contain: 
a. Start orbit - the first obit of consideration 
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b. Time span - last digit of year, day of year, hour, minute, and 
second of start and stop of the program. 

c. Cloud cOTer - orbit number, start frame, stop frame and percent 
of predicted cloud cover. 

The Area Availability Program converts the desired areas from frames to times, using 
the Ground Trace Ephemeris for the calculations. The times are frame center times 
calculated in twenty-five second increments from the time of Equator crossing. These 
times are then compared with the sun angle per time, and areas having out of range sun 
angles are either modified or removed or modified respectively to conform to their 
acceptable cloud cover. The remaining areas after deletions and modification are written 
to Available Areas Table (AATBIj). The calculated times of descending nodes and the 
times of maximum sun for each orbit is written to the descending node table (DESNTBL)a 
The operator NODTM transfers the descending node times to a section of the History 
Data Base. 


3.2. 7.2.6 Preprocessor 

The Preprocessor cards load the Station Capabilities file (SCPTBL) and the Spacecraft 
Parameters table -via the operator ADTXt The card inputs provide: 

1. Statioi Capability data as to whether the station can: 

a. Provide telemetry support. 

b. Provide real time support. 

c. Spacemaft commanding. 

2. Spacecraft parameters 

a. Which payloads may be used and which cannot be used. 

b. Number of stored commands available. 

c. Operational AOS & LOS Buffers. 

3.2. 7.2.7 Station Contact 
INPUT 

1. The Spacecraft Prediction Pile (SCP) contains all the stations that are 
predicted to have visibility of the spacecraft for a 14-day period along with 
their expected time of acquiring the spacecraft and expected loss of 
contact with the spacecrafi, and the duration of the contact. 
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2. The station capabilities file provif^es the information on what service 
each station can provide. 

3 . The time span card provides the last digit of the year, the day of 
the year, hours, minutes and seconds of the start and stop of the 
data required. 

4. The stations desired provide the information as to which stations 
are to be considered. 

The operator takes the information for the desired stations during the time span provided 
and assigns each stations GO/NO GO capabilities from the station capability file (SCPTBL) 
and writes the station contact table (STCTBL). The STCTBL is then manually edited to 
remove any unscheduled stations and/or to add back-up sites that have been scheduled 
up before the file can be used as an input to the sensor operations program. 

3.2. 7. 2. 8 Sensor Operations 

The sensor operators program consists of three separate but interrelated programs. 
These are real time, TBRSS and payload operations summary, which will be discussed 
separately, 

1. Real time program 

The real time programs the unified S-band beacon, and payload 
operations over ground stations having video reception capabilities. 

INPUTS: 

a. SCACT - The SCACT file from the previous day provides initial 
conditions. 

b. STCTBL - The STCTBL file provides the information as to which 
stations are available, the time they are available and what their 
individual capabilities are. 

c. AATBL - The AATBL file is a list of the desired available 
areas containing the times the spacecraft will encounter them 
and what their priority or effort index is. 

d. SPMTBL - The SPMTBL provides data on the spacecraft Indicating 
which payloads to schedule, and the delay time for command 
capability (after acquisition of signal and before loss of signal). 

e. ACTDFT - The ACTDFT file defines the acronyms to be used in 
constructing the SCAT, 
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f. DESNTBL - The DESNTBL file provides the times that the space- 
craft will cross the Equator going south. 

The real time program deltas the command delay time from the station 
contact times in order to identify when the station can command. It 
then forms the basic SCACT table after saving the final SC ACT from the 
previous day, adds USB acronyms, then schedules all payload activity 
that accrues within acquisition of a ground station. 


The last SCACT t^le from the previous night is then merged with 
the first SCACT table and the complete real time SCACT is written to 
the SCACT file for use by the stored program. 


2. The Stored Program 

The stored program schedules payload operations when the spacecraft 

is not within view of a ground station. The program inputs are; 

a. SCACT - The SCACT file as input to stored is the real time 
SCACT file output by real time. 

b, STCTBL - The STCTBL file as input to stored is the modified 
STCTBL as output by real time and number of SCACT tables. 

c. AATBL - The AATBL file is the same as input to real time. 

d, ACTDET - The ACTDFT file defines the acron 3 ons to be used for 
scheduling the payload operations. Unlike the real time program 
the stored program also needs the number of commands and thar 
delta times for each acronym. Since the stored program schedules 
only payload data when no ground station is in view and stored 
command capability is limited, commanding now becomes a constraint. 

e. SPMTBL - The SPMTBL file provides the information as to which 
payloads are to be scheduled. It also provides the number of stored 
commands available to the program. 

f , DESNTBL - The DESNTBL file provides the time the spacecraft 
will cross the equator going south on each orbit. The stored 
program calculates which areas will fit on the TDRSS with priority 
1 areas and works toward priority 9 areas. The constraints are 
time available and the number of stored commands available. 
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The stored program then merges the stored payload activities with 
the real time SCACT and writes a combined SCACT to the file. 


3. Payload Operations Summary 

The POS program reviews the SCACT file for command conflicts. Its 
inputs are: 

a. STCTBL - The STCTBL provides the number of schedules in the 
SCACT me. 

b. SCACT - The SCACT m.e is read in for review and corrections, 

e. ACTDFT - The ACTDPT file provides acr 003^1 definitions (command 
and delta times) . 

d. SPMTBL - The SPMTBL file provides spacecraft parameters. 


The POS program reviews the SCACT for command conflicts that occur 
between real time and stored programs. Payload on and off conflicts 
are corrected by the program. The correct SCACT is then written to 
the SCACT file in preparation of the final edit. 

3 . 2 , 7 . 2 . 9 Power Management 

The Power Management program computes the amount of power that will be utilized 
by the schedule spacecraft activities, compensation heater loads on, aux loads on and 
all other power dissipating items that are energized. The program then computes the 
solar array output for the duration of day and compares the power to be generated to the 
power to be consumed and computes the aux loads needed to dissipate excess power 
during the oribt. The aux load changes are then added to the existing SCACT. 

INPUTS: 

SCACT “ The SCACT file is read to determine the activities that are scheduled 
in order to compute how much power will be required by the payloads. 

PWRMGT - The PWBMGT file is read to determine the status of the space- 
craft power subsystem after the last run (i. e. , which subsystems were 
remaining on, which comp loads and aux loads were on and the discharge 
state) as well as constant and variable rates of power utilization or 
generation of each item. 
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STCTBIi - The station contact table is read to determine the number of 
schedules contained in the SCACT file, 

DESNTBL - The descending node table is read to determine the time of 
maximtim sun angle for the orbit. 

Cards - Modifications to the PWRMGT file are input on cards to the program, 
OUTPUT: 

SCACT - The SCACT with the aux loads added is sorted in chronological 
sequence and written back to the SCACT fhe, 

PWRMGT ” The PWRMGT table is modified to include the subsystems reamin- 
ing on and the new discharge is returned to the PWRMGT file. 

Printout - The Power Management program provides a print out of its 
operations and a summary of aux load changes and times. 

3.2. 7. 3 System Scheduler Interfaces 

3 . 2 . 7 . 3 . 1 Lands at Pr oj ect/Sy stem Sc hR dii Ung 

The interface between System Scheduling and the LANDSAT Project was establislied 
to provide a means for the project to make its requirements relative to spacecraft opera- 
tions; i. e. , Payload Operations Imown to the activity scheduling body. The interface 
also allows for the passage of data and other information related to spacecraft operations 
scheduling to the project. 

An example of this would be the request for projects resolution of a conflict involving 
requested sensor operations exceeding the spacecraft’s capability. 

3.2. 7 . 3.2 ODG/^stem Scheduling 

The System Scheduling Operation will supply to ODG; 

1. Orbit Adjust engine bum characteristics <memo) 

2. Verification of orbit adjust firings (memo) 

3. Payload operations summary (POS) 

4. Attitude Gating Summary (AGS) (memo) 

5. Orbit adjust system temperatures and pressures (memo) 

6. Requests for ground trace ephemeris listings (memo) 
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7. Requests for special STDN grovmd Station Contact Summaries (ERTSUMS) (memo) 


The ODG shall supply to System Scheduling; 

1. Station Contact Summaries (ERTSUMS) 

2. Predicted Eit Ephemeris as requested 

3. Best Fit Ephemeris as requested 

4. Station Contact Prediction Data 

5. Ground Trace Ephemeris Listings 

6. Recommended O/A Burn Times 
7 • TDRSS Ephemeris 

3 .2 . 7. 3 . 3 Network Scheduling/System Scheduling 

System Scheduling will make weddy requests to MISS CXI! for support hy remote sites and 
TDRSS. 

MISSOC will, if possible, schedule as requested and verify to system scheduling the AOS 
and LOS times of all stations that have been scheduled for LANDSAT support. 

3 . 2 . 7 . 3 . 4 NOAA/Systera Scheduling 

Once a day, NOAA will provide System Scheduling a map (Facsimile) containing predicted 
cloud coverage data that will encompass the upcoming scheduling period. Areas that 
have a higher cloud cover than permissable for picture taking will be excluded from Payload 
scheduling. Scheduling will provide the longitude of the first orbit which will position 
Ms overlay for the remaining orbits of the day. 

3 . 2 . 7. 3 . 5 CDPF/System Scheduling 

The OCC/CDPF interface is mainly through SLAT, There are two types of tapes passed 
to the CDPF from the OCC -- SLAT and WBVT, SLAT shall be the only data transfer 
media from the OCC to the CDPF that are required for the generation of image annotation 
data by the CDPF. For each WBVT interval on a SLAT, the SLAT shall provide necessary 
and sufficient data for the processing of that WBVT interval by the CDPF, 

The data tliat is required for the processing of one WBVT will be grouped in one WBVT 
file. A 'LACI Indicator' in the name of a WBVT file indicates whether the WBVT file is 
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generated for the processing of botli LACI and Landsat data or just for Landsat data. In 
the case of WBVT file is generated for the processing of both LACI and Landsat data, a 
LACI video tape directory record shall be included in the file. The SLAT version file 
shall be the first file on every SLAT, 

3.2.8 COMPUTING SERVICES SUBSYSTEM* 

The Computing Services Subsystem must provide the data processing hardware and 
software capabilities to meet the function requirements described in Section 3.2.2 
through 3.2. 7. hi addition, it must provide; 

o A bacicup capability for on-pass commanding, 
o Test, diagnostic and simulation capabilities for all interfaces. 

0 Standard software development and maintenance capabilities. 

0 A gracesful recovery capability for on-pass 

3.2. 8.1 Hardware 

The basic hardware configuration as shown in Figure 3-2 meets the Landsat-D OCC 
requirements. This ccnfiguration includes two Application Processor systems, two 
TAG systems, two Virtual Interface Processor computers and associated peripherals 
and a local switching system local IPC) for switching between the Landsat-D OCC 
components. In addition, there is local data base storage for each AP and switching 
to allow one AP to access the storage on the alternate AP (for baclcup). 

The POCCNET, if available, provides Data Base/DOCC computers and two VIP’s in the 
DOCC complex, two Gateway processors and whatever computing equipment is necessary 
to create the IPC net. 
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This configuration provides processing bacloip through the redundancy in the local 
Landsat-D pair, the redundancy in the DOCC complex and the high availability of IPC 
channels (as described in Section 5 of the Appendix to the Des Jardins, Hahn POCCNET 
description). The configuration, with appropriate software support, also provides the 
capability for on pass recovery 'through a shared scratch data base). 

3.2. 8. 1.1 The Applications Processor 

The AP in Landsat-D must have the capability to support medium-scale data manipula- 
tions problems (^stem Scheduling) and real-time data handHi^ (for data from the TAG 
computer). It must have room for at least six display partitions, a display supervisor, 
a real-time data input partition, a background partition (for the Off-line Supervisor, 
System Scheduling and software development) and a disk-based operating system. Room 
for a Data Base Management System, may also be required. (The Landsat 1/2 /C 
Sjystem has 128K 32 bit words. Tins should be a minimum) . 

ha addition, the AP must have floating point hardware and memory management hardware 
is recommended. The AP must be accompanied by sufficient peripherals (card reader, 
disk storage, tape drive, operator's terminal) to do software devetopment and maintain 
system, historical and scratch files. The disk storage should be at least large enough 
for the operating system, historical files, scratch files and software development files. 
(Landsat A/B OCC has about 40 MB. Tliis should be sufficient if tlie new Landsat-C 
historical files are adopted) . 

In addition, tliere may be a requirement for a data base that would include the user data 
that is now available only in the Landsat NDPF data base. In that case, the AP that Is 
used to backup the on-pass AP will also maintain some of the larger NDPF data base. 

This disk storage would be roughly 100MB and, wMle it would be maintained by the 
alternate AP, it vd uld be switchable to the primary. 

3.2.8. 1.2 The TAG Eastern 

The TAG computer for Landsat-D must be able to read data streams, reformat diem into 
AP messages, perform error coding/decoding, and ship the messages into the AP in real- 
time. It must also be able to read and block commands for the spacecraft and handle site 
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and NASCOM message protocols. The exbent of the problem is difficult to assess now 
because of the uncertainty in Landsat-D data rates, in the iP^to^ks in the TDRSS 
hooloip and in the encoding requirements of the multi -mission spacecraft telemetry. 

If the Landsat-D telemetry and command requirements are similar to those of Landsat 
.i/2/C, a 64KB minicomputer with hardware frame and bit syncs, about 25MB of disk 
storage and a terminal will be sufficient. It should be noted, however, that if the TAG 
computer is to handle some of the problems of the TDESS "bent-pipe" (including free 
floating frame syncs within the bloclcs) one or more microprocessors will be required 
to do some of the syncing. The Mission Operations Division is preparing an RFP for 
a standard TAG solution for the MMS and TDRSS front ends. Tins will be POGGNET 
compatible and available within the next two years. 

. * 

3. 2. 8. 1.3 The Virtual Interface Processors 

The VIP is discussed in Section 7.4 of the Appendix to the POGGNET concept paper. 

Based on Landsat A and B, the Landsat VIP's will need to support about six standard 
block displays, two line printers, one or two card readers, a graphics terminal, and 
four strip cliart recorders. Tiie specific size and capabilities of the computer would 
he best estimated by the Poccnet project. An initial estimate was a 64KB mini: A 
PDP 11/34 or equivalent, 

3 . 2 . 8 . 1 . 4 hiterf ac es and switching 

The Landsat-D OCC presented herein has interfaces among the OCG elements, between 
the two autonomous OCC groups in the pair and between the Landsat-D OCC computers 
and the Poccnet IPG, The POCCNET standard interface will call for a serial cliannel with 
bit-oriented communications protocol. It is recommended that this standard be used 
tlnn ughout the Landsat-D OCC. The adoption of the standard will allow tlie OCC com- 
puters to talk to one another or to the POCCNET with no additions for changes in protocol 
Also, it TiViU allow switching to be done on serial channels rather than parallel ones. 
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The path of co m munication between, the primary Landsat-D OCC computers and the 
alternates depends on the existence of the POCCNET. If POCCNET is up and available, the 
switching will be accomplished by the Landsat-D M40 operator via POCCNET IPC software 
c h a nn els. In addition the standard POGG configurations will be manually patchable via 
serial patchband (VIP-AP-TAC configurafLon), 

3. 2. 8.2 Software. 

) 3 . 2 , 8 . 2 * 1 Operating Systems 

The Applications Processor must have a disk-based, multi-tasidng operating system. 

It should include memory protection features, a file management system, inter-task 
communications, prioritorized task management and hooks for user interrupt handling. 

It should also have clear operath^ procedures, proven system, utilities, a batch capa- 
bility and readable user documentation. It must have demonstrated support fcy the vendor. 
(This should be true of all the vendor software}. 

The TAG and VTP computers should have an operating system that is compatible witli 
the AP operating system. (Compatibility is not required, however, if these systems 
are provided by the POCCNET project), 

3 . 2 . 8 . 2 . 2 Seal-Time Executives 

The executive software provides the coordination between the applications functions, the 
operating system, and the users. It is inextricably married to the operating system. The 
Landsat 1/2/C ^stem Real-Time Executive for the applications computer is written to 
interface with the Sigma 5 BPM operating system. If the Landsat-D OCC Sgma 5 is 
replaced, BPM would also be replaced. The Executive (and most of the real-time appli- 
cations programs as it turns out) would then have to be redesigned. 

The current front end processor (the TAG) for Landsat is a Sigma 3. It uses an in-house 
executive and operating system. New devices drivers and new requirements cannot easily 
be accommodated. If the Landsat OCC is to handle 4800 bit blocks or TDRSS or if it is to 
fit into POCCNET, it woo would have to be replaced. 


3-36 



3. 2. 8.2. 3 Software Development 

The Landsat-D OCC should have the capabilily for Ml software development (independent 
of POCCNET). Each computer should come with a macro assembly language (hopefully) 
the same one) and a re-entrant Fortran compiler. (Hopefully, a new standardized 
FORTRAN will be available). 

All microprocessors must be supported by cross assemblers that can run on a computer 
within the Landsat OCC. 

All software maint^ance and development will be controlled under a configuration con- 
trol plan similar to the one on the current Landsat NDPF. 

3.2. 8. 2.4 Tests and Diagnostics 

All vendor equipment should be accompanied by diagnostics. For the computers, these 
diagnostics should be able to run under tlie operating system. For all other equipment, 
a memory partition should be reserved such that the diagnostics may be able to run on- 
line (where this does not interfere with normal system performance) from the M&O 
console. 

In addition, the M&O console operator will be able to reconfigure the OCC system and 
run interface tests between any two computers or between the VIP and any peripheral. 
The M&O console will, therefore, Imow the status (on-line, off-line or test) of all data 
processing eqiiipment. 

3 . 2 . 8 . 2 . 5 Data Base Management 

The Landsat-D OCC Applications processor will have an operating system that supports 
indexed and random files. The application programs will, with the aid of library file 
access programs, be able to access any record in the data base. Fur tin r stutfy must 
be done to decide whether a vendor supplied Data Base Man^ement System that would 
allow data base element access is required. (The DBMS would malce files transparent 
to the user.) TMs study will have to take into account Landsat-A/B/C experience and 
Landsat-D expansion requirements. 
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3.2. 8.2. 6 POCC NET Interface 

All computers that interface with the POCCNE Twill have POCCNET device drivers and protocol 
modules tliat adhere to the POCCNET protocol standards. Computers tliat talk to one 
another within the Landsat OCC should also follow these protocols in their conversations. 

This would allow the location of one computer to be transparent to the software of the 
other computer. 

In addition, if the POCCNET Data Base System is to be used (as for picldng up ephemeris) 
data), die Landsat Applications processor will require Imowledge of Data Base protocols 
(e. g. , how to access a file). 

It may also be necessary for the OCC to Imow how to send requests to the DOCC for 
POCCNET equipment reconfigurations 

The extent of the POCCNET interface software will depend on how elaborate all tlae message 
and communication protocols are. The POCCNET protocol standards document is due to 
be published within the next three months. 

3. 2. 8. 2. 7 Standard Test and Operations Language 

The purpose of the STOL is to allow the required operations of the OCC to be sent to tlie 
computers through a standardized source language. The language macros would be 
developed and documented by the Landsat-D OCC operations personnel and programmers. 

It would be interpreted by a program in the Applications computer. Macros would he 
developed according to the need to automate the OCC functions. STOL and its interpreter. 
Autopilot, are described in Section 2. 8 of tlie Appendix to the Pocenet concept paper. 

3 . 2 . 8 . 2 . 8 Switcliing S of tware 

The Laudsat-D OCC data processing components need to communicate and the communi- 
cation channels must be allocated and controlled. The POCCNET IPC cliaimel s 
configured by the POCCNET DOCC. The Landsat-D OCC will requim a limited version of 
the POCCNET DOCC for internal redundancy. One of the possible methods of implemen- 
tation of this small network is through a micro-processor and a user CKT. The micro- 
processor would be programmed to accept user configuration commands (in STOL) and 
to set up the computer-to-computer channels accordingly. Network topologies will have 
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to be investigated, however, a starting point should be a duplicate of the POCCNET topology. 
Another approach suppcrt in POCCNET is to allow the Landsat-D DOC limited autonomy 
in reconfiguring his assigned resources within the POCCNET TPC without requiidng the 
approval intervention of the POCCNET DCCC. These alternative approaches should be 
investigated further to make a final decision. 
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APPENDIX A 
LIST OF ACRONYMS 


AP 

Applications Processors 

CCL 

Closed Circuit Loop 

CRT 

Cathode Ray Tube 

CCS 

Command Compilation Softw'are 

C&DD 

Communications and Data Distrlhutioii 

CDPF 

Central Data Processing Facility 

CMS 

Command Management Software 

CSS 

Computer Subsystem Switching 

DBS 

Data Base Storage 

DCS 

Data Collecticm. Subsystem 

DIS 

Data Input Subsystem 

DOCC 

Data Operations Control Center 

DOMSAT 

Domestic Communications Satellite 

DMG 

Data Management Group 

FDG 

Flight Dynamic Group 

GMT 

Greemvich Mean Time 

GSR 

Generalized Statistics Routine 

IPC 

Inter- Processing Communications 

M&O 

Maintenance and Operational 

MMS 

Multi-Mission Modular Spacecraft 

MTR 

Magnetic Ihpe Recording 

NASCOM 

NASA Communications 

NTTF 

Network Test and Traitmig Facility 

OCC 

Operations Control Center 

ODG 

Orbit Determination Group 

OLS 

Off-Line Supervisor 

OFPAS 

Off-Line Processing and Analysis Software 

ONPAS 

On-Line Processing and Analysis Software 

OS 

Operations Supervisor 



PBX 

Private Branch Exchange 

PAS 

PCM Acquisition Supervisor 

PCM 

Pulse Code Modulation 

PDF 

Plot Data Formatter 

POCC 

Payload Operations Control Center 

POCCNET 

P^load Operations Control Center Network 

RBS 

Report Data Supervisor 

BDT 

Raw Data Tape 

RGP 

Report Generator Packages 

RGS 

Report Generator Supervisor 

RT 

Real-Time 

RTC 

Real-time Command 

SCAIVIA 

Switching Conference and Monitoring Arrangement 

scs 

Signal Conditioning and Switching 
\ 

SLAT 

Spacecraft Location Attitude Tape 

SRE 

^stem Request Executive 

STDN 

Space Tracking and Data Network 

TAG 

Telemetry and Command 

VIP 

Virtual Interface Processor 



